SCA Challenges in a Cloud-Native Environment
Microservices and cloud-native environments have changed the way we design software. We no longer build software systems based on a single codebase scanned for Software Composition Analysis (SCA) and compiled into a set of binaries that are released together.
Instead, our monolithic systems are decoupled into smaller, reusable functions deployed independently. Each function, or microservice, goes through an independent build process and pipeline. Each microservice is scanned independently with its own Software Bill of Material (SBOMS) and Common Vulnerability and Exposure (CVE) report for every released version.
The result is hundreds of SBOMs, CVE reports, and other critical DevOps intelligence data spread across our software supply chain that is consumed by our software systems. We now need to begin to report on the ‘logical’ application the same as we reported on our monolithic applications.
We are often asked if we can show service to service level dependencies. The real questions to ask are, “how do you expose service versions to logical application version dependencies,” and “how do I generate the needed DevSecOps reporting for my cloud-native application?”
Aggregating SCA to a Higher-Level
Managing the relationships between services and ‘logical’ cloud-native Applications is required to begin the process of aggregating Software Composition Analysis and supply chain data to a higher level. In this context, we define these terms as follows:
- Components: Your supply chain, such as a microservice, open-source packages, database SQL, infrastructure change, file updates, etc.
- Applications: An Application is a collection of Components.
An update to a Component has an immediate impact on all ‘logical’ Applications that consume it. For example, a new microservice version released into a cluster automatically creates a new version of the consuming ‘logical’ Application. No Application build was required.
In fact, a single microservice update could cause multiple ‘logical’ Application versions to be created. For each new ‘logical’ Application version, new Software Composition Analysis reporting must be done. This means that the tracking of the many-to-many relationships between Components and ‘logical’ Applications must be automated and stored in a central location.
In a cloud-native, microservice architecture, you will find yourself asking several important questions, such as:
- “Why is there a new version of my ‘logical’ Application?”
- “What Component caused the change?”
- “Where are the new SBOM and CVE reports for the new Application version?”
- “Is the new updated Component running on all Clusters, or do I have a drift problem?”
- “Who released this microservice update?”
Centralizing Software Composition Analysis
Centralizing and automating the collection of Component level Software Composition Analysis is an essential tool in the DevSecOps toolbox for cloud-native architectures. Without a central ‘evidence store’ of this data, it is nearly impossible to determine if the ‘logical’ Application you are delivering to your end users is safe for consumption. And instead of each team carefully managing the release of new monolithic application versions, an application could be impacted without the developers ever knowing that a change occurred.
Using a central governance catalog provides a metadata store that exposes how your ‘logical’ applications are configured and inform stakeholders on insights for the system, including Software Bill of Material and vulnerability reporting.
DeployHub’s Evidence Store of Component to Application Data
DeployHub provides a central ‘Evidence Store’ of supply chain data, including the Component to Application dependencies across your entire supply chain. It consumes Software Composition Analysis data and tracks it for each Component version.
Once DeployHub detects that a new Component version is available, it automatically creates new versions of each ‘logical’ application that has been impacted, aggregating all of the SCA data to the highest level. DeployHub hooks into your DevOps Pipeline to collect Component metadata.
A Baseline of Your Logical Application
A ‘logical’ view of your Application is a critical piece of understanding your changing supply chain in a decoupled architecture. DeployHub allows you to define a ‘baseline’ application package to prime the pump. With DeployHub, development teams define their ‘Application Baseline Package’ by providing a Component .toml file, or by using a ‘designer’ drag and drop process. The Application Baseline is then used to track and progressively version your application changes over time, based on changes to the underlying Components.
Each time a Component is updated, all Supply Chain intelligence is gathered. DeployHub automatically creates a new Application version for any ‘logical’ Application that was impacted by the change and aggregates the Component Software Composition Analysis to the ‘logical’ application levels.
While we may no longer need monolithic applications, we still need to understand and secure the software systems we send to our end users. DeployHub’s centralized evidence store and versioning engine provide the insights needed to allow Developers, DevOps, and Security Engineers to reason about the systems they are creating and delivering to customers around the world.