Modern software is composed of multiple open source libraries, the average project has hundreds of external dependencies. This is true for almost every part of your stack, from the vast npm-dependencies in the frontend to your SpringBoot microservices in the backend.

So, without any exaggeration, the part of the code you write and have under full control is just the tip of the iceberg.

The whole software supply chain is a target for attackers and the attacks have tripled in 2021 and are expected to rise exponentially in 2023. There are quite a few attacks that are carried out and that can compromise your software. These attacks are not only theory, they happen in reality, as illustrated by the SolarWinds, log4j, Spring4Shell, Kaseya, and OpenSSL incidents. So it is really important to make sure that we secure each link of the chain, because if one fails, everything will be affected.

In November 2021 President Biden issued the Cybersecurity Executive Order in which Section 4 directs various federal government agencies to take certain actions to enhance software supply chain security.

Also in November 2021, the National Telecommunications Information Administration (“NTIA”) released two documents related to its ongoing efforts to establish standards for Software Bills of Materials (“SBOM”). The first document SBOM Myths vs. Facts intends to help dispel “common, often sincere myths” about SBOM. The second document identifies various initiatives, guidance, models frameworks, and reports that expressly or implicitly highlight the value of SBOM.

What is a software supply chain?

In software development, the “raw materials” of the supply chain are common libraries, code, hardware, and tools that transform code into a final deliverable, like compilers, packers, scripts etc. The deliverable can be deployed as either a user-facing (web/mobile)-application, a service/API, an “internal” library or another package artifact that is included as a dependency as part of a different product.

If you want to take a look at your SpringBoot Gradle-Dependencies , just type:

gradle -q dependencies 

The resulting dependency tree shows, whcih dependencies are used for compile, test and runtime:

compileClasspath - Compile classpath for source set 'main'.
+--- org.springframework.boot:spring-boot-configuration-processor -> 2.6.6
+--- org.projectlombok:lombok -> 1.18.22
+--- org.springframework.boot:spring-boot-starter-actuator -> 2.6.6
|    +--- org.springframework.boot:spring-boot-starter:2.6.6
|    |    +--- org.springframework.boot:spring-boot:2.6.6
|    |    |    +--- org.springframework:spring-core:5.3.18
|    |    |    |    \--- org.springframework:spring-jcl:5.3.18
|    |    |    \--- org.springframework:spring-context:5.3.18
|    |    |         +--- org.springframework:spring-aop:5.3.18
|    |    |         |    +--- org.springframework:spring-beans:5.3.18
|    |    |         |    |    \--- org.springframework:spring-core:5.3.18 (*)
|    |    |         |    \--- org.springframework:spring-core:5.3.18 (*)
|    |    |         +--- org.springframework:spring-beans:5.3.18 (*)
|    |    |         +--- org.springframework:spring-core:5.3.18 (*)
...
(*) - dependencies omitted (listed previously)

You notice that below your top level dependencies, that you explicitly specify, there is a myriad of transitive dependencies, dependencies of your dependencies.

So by now it is clear, that you have to:

• Know your dependencies, including transitive dependencies, understand the risks of those dependencies, such as vulnerabilities and licensing issues.
• Actively manage your dependencies - when a new security vulnerability is discovered, you will want to get notified. Then, determine if you’re impacted, and if so, update to obtain the latest functionality and security patches. Plus: keep a hold on your dependencies by carefully reviewing changes that introduce new dependencies and periodically remove unnecessary dependencies.
• Monitor your supply chain. Introduce controls to manage your dependencies, move from audit to enforcement to prevent drift in your supply chain.

But how can you accomplish this? The key is automation.

Software Bill of Materials (SBOM)

We want to automatically inventarize the components and libraries that our software is made of. We can do this by generating the dependency tree to a file in a machine readable format.

The interesting data about your software supply chain libraries includes:

• who is the author of it
• date of contribution
• if and how it’s been reviewed for security issues
• known vulnerabilities
• supported versions
• license information

It would be impractical to use some proprietary format for each tool, so we should take a look at standards in this field and how this enables us to use an ecosystem of tools for software supply chain security.

Conclusion

In the next post we take a look at software bill of material standards and show how we can automatically generate SBOMS for our software projects. After that how we can use these SBOMS with tooling to achieve continuous monitoring of our software supply chain.