Among the top cybersecurity projects for CSOs in 2025 is “establishing asset visibility and strong cloud governance.” But what does this mean in practice? Many organizations have a good handle on their data storage and compute infrastructure. However, while they may know which virtual servers or serverless platforms are in use, they often don’t know what’s in the applications that are running. The Log4Shell vulnerability was a wakeup call: companies scrambled — and often failed — to find all affected systems.
Why it Matters
The pace and sophistication of attacks continue to increase. The model of a lone hoodie-wearing hacker sitting in a dark room defacing websites doesn’t represent the modern threat landscape. Attackers are large, organized operations, often crime rings or even nation-states. They’re not just going after the easy targets; they’re going after impactful targets: companies that can afford to pay large ransoms, critical infrastructure controls, and government databases. Sometimes the motivation is purely financial, sometimes it’s geopolitical. Either way, attackers are well-resourced and determined.
Even if your organization isn’t the direct target, you can fall victim to attackers. A supply chain attack designed to gain access to a bank, for example, could also poison your supply chain. The attackers will gladly take your customer information or hold your servers hostage to ransomware.
Modern software supply chains are incredibly complex webs of third-party code. To properly secure the supply chain, organizations must first gain visibility into all of the components that go into their applications. This is necessary not just on a per-application basis, but across the entire portfolio. From there, organizations can make prioritization decisions based on context and set automated policy enforcement to ensure that applications are securely developed and deployed.
Security requires constant vigilance, and vigilance requires visibility. How can you hope to secure what you can’t see? That means you need to know what goes into your software and you need to know where that software is running. The faster you can start fixing vulnerabilities instead of looking for them, the quicker you’re protected against the latest attack.
Challenges in Securing Your Supply Chain
Most of your software isn’t yours. In other words, your employees didn’t write it; they brought in third-party dependencies. Whether from vendors or open source projects, these libraries provide a foundation that allows your developers to focus on the differentiated functionality that your company provides, which speeds your innovation and delivery.
The tradeoff for this increased speed is taking on the risk of your dependencies’ security posture. Do you know what vulnerabilities exist in your dependencies? If you do, you can’t necessarily fix them yourself. Even if you have a good relationship with the providers of your direct dependencies, they have their own dependencies, and these transitive dependencies can number in the hundreds and be several layers deep. How do you track all of those dependencies for vulnerabilities?
Once you know what vulnerabilities exist in your supply chain, do you know where the vulnerable versions are deployed? 10 days after the Log4Shell vulnerability was announced, less than half of the publicly-reachable vulnerable applications had been patched. That’s a big window for attackers.
Knowing where all of the vulnerable applications are running doesn’t give you the full picture. Just because an application contains a vulnerability doesn’t mean the vulnerable part of the code is used. It may be the case that your application doesn’t call the vulnerable code path or that the vulnerability is conditional on a configuration that you’re not using. While you may still want to address the vulnerability, it’s not as high a priority if it doesn’t affect your current application portfolio.
Establishing Visibility and Governance
Thankfully, you can overcome all of the challenges. The first step is to start building software bills of materials (SBOMs) at build time. The SBOM records what goes into your software, so it is the foundational piece of building asset visibility. You can then use that information to build a knowledge graph about your supply chain, including vulnerabilities and software licenses. When you aggregate these SBOMs across all of your application portfolio, you get a holistic view of all dependencies.
This portfolio-wide view helps you prioritize which issues to fix first. The impact of fixing a vulnerability in one or two applications is a lot less than fixing a vulnerability in all applications. Similarly, fixing a vulnerability in a production, external-facing application is more impactful than fixing a vulnerability in an internal development environment.
As mentioned above, knowing if a vulnerability even affects the application that contains it is a key part of the overall visibility picture. Ingesting VEX (Vulnerability Exploitability eXchange) statements, when available from your dependencies, will help you eliminate the vulnerabilities that are irrelevant to your code. Runtime analysis, like with eBPF, adds more filtering by determining which code paths are actually loaded into memory. This gives you more detail on which vulnerabilities are exploitable in your specific application, especially when VEX statements aren’t available.
Context-aware prioritization makes responding to issues easier and faster. But what’s even better is preventing issues in the first place. Creating SBOMs at build time means you can enforce policies to prevent issues. For example, you can use the SBOM that you just produced in the build pipeline to check for known vulnerabilities in the dependencies and block merging the code into the main branch if it contains vulnerabilities or if it has a poor security posture. After build, tools like Kubernetes Gatekeeper can automatically enforce policies to block deployment of applications with critical vulnerabilities, missing or incorrect cryptographic signatures, and other security concerns.
One final piece of the puzzle is tracking software provenance. Tracking and gating on software provenance gives you another avenue to protect yourself from vulnerable code. This is often overlooked, but given the prevalence of attacks against open source library repositories, it’s more important than ever. Provenance is a provable record of how software was built, where it was built, and by whom it was built. These cryptographically-signed attestations mean that you can know if the package you downloaded from npm came from your dependency’s official build system or from hackerman9000’s laptop after he compromised the project’s npm account. But provenance doesn’t just help with deliberately altered, it also gives you a sense of the security practices used in the build process. Standards like SLSA give you assurance that builds took place in environments with sound security.
Start Somewhere
Implementing all these practices takes work and cultural change. You don’t have to do everything at once; each step you take reduces risk. For example, we know that SBOMs alone won’t solve supply chain issues, but having them is better than not having them. Once you have SBOMs, you can build on them to collect more data. Don’t let the perfect be the enemy of the good. After all, security is a process, not a destination.
