Try Vulcan Free: The only free tool for risk aggregation and prioritization | Get started now >>

Vulcan Cyber launches new Attack Path Graph feature | Learn more >>

CVE-2023-2640 & CVE-2023-32629: How to fix the new vulnerabilities in Ubuntu Kernel | Learn more >>

Understanding vulnerability risk: The best practice guide for cyber risk management, from Vulcan Cyber users | Read more >>

Try Vulcan Free: The only free tool for risk aggregation and prioritization | Get started now >>

Vulcan Cyber launches new Attack Path Graph feature | Learn more >>

CVE-2023-2640 & CVE-2023-32629: How to fix the new vulnerabilities in Ubuntu Kernel | Learn more >>

Understanding vulnerability risk: The best practice guide for cyber risk management, from Vulcan Cyber users | Read more >>

GET A DEMO
Perspectives

Software supply chain challenges and more: first officer's blog - week 49

Software supply challenges, a new congressional push for cyber security testing, and more. Here's the latest from the world of cyber risk.

Mike Parkin | May 01, 2023

The ongoing voyages of the Federation Support Ship USS [REDACTED] 

First Officer’s log, Terrestrial date, 20230501 Officer of the Deck reporting.  

By running at our maximum cruising speed, the USS [REDACTED] arrived at the conference with time to spare. This let us get everything set up and properly prepared for the various meetings, presentations, and demonstrations that were normal for these events. 

For most of the ship’s compliment, these events were a mix of social interaction and continued education. It gave us a chance to exchange knowledge with other crews in our field, and with crews who either relied on our expertise or didn’t yet know they needed it.  

That was sometimes the larger challenge. You wouldn’t usually describe our role as exceptionally glamorous. We weren’t doing First Contact duty, or patrolling the [REDACTED] Neutral Zone, or conducting deep reconnaissance of the [REDACTED] Nebula, but what we did was still vital. As a support cruiser, we had a clear role, a well-defined mission, and a crew who was extremely adept at it. But there were times we had to clarify what we didn’t do as much as what we did. 

Of course, it helped that people were familiar with some of our recent exploits, including the encounter that had delayed our arrival. It made for some rather entertaining conversations, both at the conference and at some of the social gatherings in the evening. 

Still, even with the combination of social and professional interaction, it would be nice to return to our primary mission. 

Breaking that 4th wall – again  

Another RSAC conference done, with quite a few good conversations and some useful insights both from attendees and some of our fellow exhibitors. Though, surprisingly, no one came by to take me up on the Sightglass offer. Which was a shame. My fresh ground coffee made in an Aeropress was better than anything else on the show floor if I do say so myself.  

Fear not though! The good stuff did not go to waste. It just went mostly to our own crew. 

Software Supply Chains remain a challenge 

What happened 

A recent article pointed out some of the challenges facing the software supply chain and its reliance on various Open-Source projects. The challenge in many cases is who may be liable for issues when there may be multiple layers of dependencies, with non-commercial entities often involved with creating and maintaining common libraries. 

Why it matters 

This article’s timing is fortunate, as this is an important topic and there are efforts in progress to help solve some of these issues, from the adoption of SBOM (Software Bill of Materials) to the recent release of the Open Source Security Foundation (OpenSSF) releasing v1.0 of their SLSA (Supply-chain Levels for Software Artifacts) framework. 

While I am a big fan of OSS, I recognize there are some real-world liabilities when an organization relies on core functionality that was developed by volunteers.  

What they said 

This one got plenty of attention.

If they can only implement it right… 

What happened 

Under a new Congressional bill called “The Critical Technology Security Centers Act of 2023” the US Department of Homeland Security (DHS) would be tasked with creating cyber security testing centers to evaluate and test critical software used by the federal government. “These centers would strengthen the capacity of the U.S. government to test the security of critical technologies and, when appropriate assist in identifying vulnerabilities, developing mitigation techniques with relevant original equipment manufacturers, and supporting new and ongoing efforts to certify technologies as secure,” according to a spokesperson. 

Why it matters 

On some levels, this is an excellent idea. The federal government’s computing systems and networks could use a unified and coherent way to test and certify the security of their myriad devices. On the other hand, well, it’s DHS and the federal government. There’s no guarantee that the implementation won’t get mired down in bureaucratic quagmires. 

Fortunately, there are a lot of government, academic, and commercial entities that are doing much of this kind of work already. The new legislation has the potential to coordinate and fund this work in a way that can get it to the people who need it, reducing risk to critical systems. The challenge will be negotiating all the steps between legislation and operation, which can prove to be problematic. 

What they said 

It’s no surprise to see plenty of people talking about this story.