Get more 5-minute insights about dev trends every 3-4 weeks. To subscribe you need to code your way there via the home page (or the easy way here)...

SBOM

The software components librarian you never had.

TL;DR:

• Problem: It’s very hard to have visibility into your dependencies and mitigate software supply chain attacks.
• Solution: A standardized, machine-readable list of components that make up your software.
• In Sum: Software Bill of Materials (SBOM) is already widely used in the security and compliance space, it may become even more prevalent with AI generated code.

How does it work? 💡

(PS. ChatGPT was not used in the creation of this issue)

The concept “Bill of Materials” (BOM) was first used in manufacturing processes to keep track of the parts used to make a product. If defects were discovered in a specific part, the BOM made it easy to find that part and resolve the problem. Software Bill of Materials (SBOM) is the same concept but for software development.

In 2021 the White house recommended that all federal organizations adopt SBOM as a security measure. This was timely with the notable Apache Log4j vulnerability and SolarWinds attacks.

Without visibility into what makes up your software, you could be compromised by some transitive dependency that is already compromised and you depend on.

An SBOM is a standardized machine-readable list of all software components that make up your application. SBOMs usually include your application’s third-party libraries, script, CI/CD application, artifacts (e.g., Docker), licenses, relevant versions, and the relationships between them.

That way, SBOM-aware products can easily scan your SBOM to find issues.

Some of the common formats for SBOMs are CycloneDX (from OWASP), SPDX (Linux foundation), and SWID (NIST).

SBOMs are typically generated each time there is a change in your software dependencies. SCA (software composition analysis) is another term you should know, it works on top of the SBOM to automate checks for vulnerabilities.

Who is this for? ✅

• Anyone producing software in critical places.
• Software buyers, as well as sellers, who want to assess security and compliance.

Why? 🤔

• Impact analysis: It enables us to answer questions like: “Am I affected by this security vulnerability?” or “Where am I affected?”.
• Dependency Visibility: With an SBOM you have much better visibility into your software and what makes it up. You can also spot outdated or subpar dependencies and find alternatives. It can help migrations to ensure your dependencies are supported in the new platform.
• Compliance: SBOMs enable compliance with legal licensing requirements of open-source components.
• Standardization: SBOM conventions allow you to share and use the same tools to inspect and analyze a piece of software.
• Due diligence: Having an SBOM is sometimes a requirement for DD purposes, having one ready could move those processes faster.

Why not? 🙅

• Overkill: For many smaller players, an SBOM is a waste of time, unless you need the benefits (mainly security visibility & compliance). You can wait until a customer or stakeholder requests it.
• Bad in the wrong hands: A malicious actor with access to your SBOM can have a much easier time figuring out what is easy to exploit. Also, there could be a concern of giving up IP by disclosing the dependencies your closed source software uses - keep your SBOM safe!

Tools & players 🛠️

• syft - A CLI tool to generate SBOMs.
• @cyclonedx - CycloneDX’s GitHub repo with several SBOM generators for different stacks.
• Trivy - Aqua Security’s open-source SBOM scanner.
• Black Duck - Synopsys’s “software composition analysis” offering (includes SBOM features).
• Xray - JFrog’s SBOM solution.
• SBOM Management - FOSSA’s SBOM management platform.
• sbom-tool - Microsoft’s SBOM generator.
• Mend SCA - Mend’s SBOM solution.
• Apiiro SCA - Apriiro’s SBOM solution.

Forecast 🧞

• More dependencies: With the prevalence of dependency managers like npm and the use of open-source dependency hell, I can see how this problem isn’t going away, an SBOM will continue to be essential.
• AI writing code: Having code generated by AI means we will have much more code generated, which means we will have many more dependencies introduced without really knowing what comprises our software - an SBOM seems to be even more relevant when that happens.
• Requirement: The concept of SBOM has gained significant traction in recent years, as regulatory bodies and industry standards organizations have begun to require or recommend its use as a best practice. According to the 2022 Executive Memo, federal agencies may now require SBOMs for critical software.
• Not enough: I already see companies adding more elements in addition to SBOM like oxsecurity’s PBOM or an HBOM and even Crypto BOM. Adding runtime information like configuration and environment data will create a more encompassing solution - I’m waiting to see which standard will prevail.

Examples ⚗️

• Use cases from CycloneDX.

Extra ✨

Additional information that is related to the subject matter:

• The SPDX GitHub.
• Gitlab’s SBOM guide.
• NIST’s guide on generating an SBOM.

Thanks 🙏

I wanted to thank @TomGranot (the best growth person I know) - he also raised the AI generated code concern!

EOF

(Where I tend to share unrelated things).

I just finished leading a class at Masterschool (success-based bootcamp). My students just finished their course 🥳 and are looking for places to work - if you’re looking to hire full-time or even some freelance work from amazing junior engineers - check them out.