How SBOMs Help You Maneuver in the Cyber Kill Zone

Hayden Smith • Jan 16, 2024

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!

< Older Post

Newer Post >

Where the Wild Things Are: A Complete Analysis of Jia Tan’s GitHub History and the XZ Utils Software Supply Chain Breach

By Hayden Smith • 02 Apr, 2024

The following is a story about the recent XZ Utils security breach and how things came about. For more context on the exploit, take a stroll over to here . What can I say? My mother only read me picture books growing up. Once upon a time there was a software developer, belonging to a nation-state that was an extremely patient and persistent attacker. They created a GitHub account on January 26th 2021.

Software Supply Chain Defense: Colorama, GitHub, and More

By Hayden Smith • 26 Mar, 2024

Recently, there was an attack targeting 170k+ GitHub users in a very complex attack that leveraged a lot of different tricks in the book including stealing session cookies, account takeover, dependency confusion and dependency hijacking just to name a few. I think all of the NVD drama drowned this out, but it's a pretty damning indicator of persistence to commit a software supply chain attack by adversaries which have planted this since *squints at watch* early February! Attackers are patient and can fool anyone, even maintainers who are the trusted guardians of a repository. Today, we will discuss lessons learned from the attack and some easy things your teams can do to protect their organization. 1. Anyone can be a target. Yes, that means you: Again, we are really cautious about putting out any FUD, but when we find a package as widely used as Colorama, anyone can fall victim to an attack as widespread as this which impacted just your every day developers doing their own projects after logging off of the 9 to 5. It’s time to step it up. It’s time to step it up and gain visibility into your software supply chain ( Cyber Kill Zone Tenet #1). SSC Defense: Incorporate security tooling into your CLI. When you are pulling packages, validate your packages being pulled are coming from legitimate upstream sources. S/O to my good friends over at Phylum which provides a fine tool to help protect your source code via blocking malicious packages from being downloaded onto your machine: https://docs.phylum.io/ 2. The Details Matter: The only difference between the legitimate website versus the poisoned domain was Python hosted versus PyPi hosted. Here is a screenshot from the CheckMarx blog, which you can find here .