Last week, I released a blog about key indicators your organization is standing in the Cyber Kill Zone. Today, we will be leveraging the best open source tools centered around software bill of materials (SBOM) and software supply chain visibility to move your team out of the Cyber Kill Zone and into safety to prepare for the next threat.

One of the best ways to move out of the Cyber Kill Zone is to know the software you are consuming, building and shipping within your environment. A great resource to do this is by continuously generating SBOMs to prepare your organization for a software supply chain threat. By continuously generating SBOMs and interrogating that data, you can start to paint a pretty realistic picture of your attack surface within your software supply chain by gaining an accurate inventory of all of the software being used by your teams.

The reason Hunted Labs places this as the highest Cyber Kill Zone factor is due to the rising popularity of software supply chain amongst APT groups because there is a massive attack surface for attackers to enter the system, allow for mass proliferation of an exploit against a wide range of targets across different sectors, and are extremely difficult/expensive to remediate once a breach has occurred. A few very recent examples include penetrating software repositories that could proliferate across a wide range of targets through different verticals, hijacking software products with default configurations for cryptomining purposes, and leveraging vulnerabilities in existing software being leveraged by you and/or your customers.

That isn’t FUD. That is just a very brief history lesson!

Continuously inventorying your software components to understand your own attack surface is now easier than ever because of the speed of software development in the open source community to deliver easy-to-use security tools to help people generate SBOMs. Let’s break down some free tools you could use to maneuver out of the Cyber Kill Zone:

Trivy: Trivy is one of the most popular open source tools for both SBOM generation that can generate an SBOM from a local filesystem, image, and/or running container on a Kubernetes workload. Utilizing Trivy, users can easily generate a software bill of materials for their source code, images, and even running containers they have in Kubernetes for free. This allows users to leverage the Trivy Kubernetes Operator to not only generate a SBOM against a running container, but also gather useful security artifacts in the process. It’s an extremely versatile tool going well beyond just SBOMs while also providing almost no learning curve for new users.

Give it a try:

trivy image --format cyclonedx node:latest

Syft: Syft is fantastic given the wide range of language support, ability to convert between SBOMs back and forth between formats, ability to use it on local source directories, and scanning images in CI before pushing to protected registry. Syft is also really nice to use because if your dev teams are already using docker anywhere in their build process, Syft can be easily invoked to generate SBOMs by simply running the `docker SBOM` command which easily generates SBOMs in any format desired.

Give it a go below:

syft node:latest -o spdx-json

Open Source Insights: TLDR; My favorite open source tool for understanding your attack surface in your software supply chain because it visualizes the complexities within your software. Open Source Insights maintains an API to work into your workflows as it maintains security and license data for over 50 million packages from npm, go, rust, nuget, and java ecosystems. This tool can be leveraged by beginners or seasoned pros, whether you already have a software supply chain architecture deployed or you are a security team trying to better understand your software supply chain. You could even use this during a post-mortem, red team recon, or open source intelligence for receiving cyber threat intelligence on a package and/or CVE.



Dependency Track: Dependency track is very well known and used by a lot of organizations — for good reason. You can load multiple projects from across your organization, centralize that data, and interrogate that software in your org in many different ways such as flagging out of date software or software components violating certain license compliance policies. You can also use component identities that help many organizations automatically enforce deny-lists for malicious packages.

I’m sure I missed something…

Sincerest apologies if I overlooked something on these tools. However, this list was curated based off of field experience, community feedback, and adoption. These tools were identified as the most leveraged assets that are helping people move out of the Cyber Kill Zone everyday and I hope they can help your organization too. If I missed a open source tool, I would love to hear about it!

Better Practices around SBOMs Should You Choose to Use Them:

• Centrally store the software bill of materials data and create a rollover policy for deleting this data e.g. Roll it to cold storage after 180 days. This allows you to not have to wait for CVE’s to be published. If you receive an alert or piece of threat intel on a specific package, you can query it immediately.
• Generate multiple SBOMs at various stages of the SDLC that can demonstrate diff between software at various stages. SBOMs are a great snapshot in time of software. As software is built, packages are normally removed/added as needed.
• Automate the generation and signing of SBOMs in your development process so that they aren’t forgotten about. Make doing the right thing easy for everyone!
• Check those packages gathered by your free tools for malware, typo-squatted packages, dependency hijacking/poisoning etc. This is why it is important to store the SBOM as it makes itself a useful security artifact to interrogate continuously and prepare your org to respond to attacks accordingly.
• Start to create lists of unauthorized/authorized versions of software packages. This can help build out automated enforcement to deny malicious packages.

Conclusion

I hope this blog will empower both developers and security teams by showing how to gain useful insights on your software supply chain and manage the ever growing attack surface within. Using this tools and better practices, you will be setup for next week where we take this sh*t to the next level by tracking exploited vulnerabilities, EPSS, VEX, and much more!