Agencies Benefit from incorporating SBOMs into Build:
- Secure by Design: ensures 3rd party SW compliance (i.e. no prohibited countries)
- Vulnerability Management: ID Risk quickly
- Lifts Patch Management
During the 2023 Singapore Cyber Week Conference, CISA Director Jen Easterly presented, “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure Design Software.” An update to their “Secure by Design” guidelines issued Oct. 25, 2023, CISA focused on software bill of materials (SBOM), an application component inventory, as key to Software Supply Chain integrity.
Integrating an SBOM capability into the DevSecOps process is also recommended in the multi-organization publication, “Securing the Software Supply Chain: Recommended Practices for Developers” and endorsed by NSA and CISA, available here.
While we use Python examples in this article, the principles are applicable to any higher-level software development languages.(Review languages and other CloneDX tools here: CycloneDX Tool Center).
To allow SBOMs to be machine-readable for reporting, three specifications are currently available: Software Package Data eXchange (Linux Foundation), CycloneDX (OWASP) and Software Identification Tags (SWID). Here, we focus on the CycloneDX aspect using the CycloneDX Python SBOM Generation Tool (https://github.com/CycloneDX/cyclonedx-python).
SBOM
To generate an SBOM for a Python app, you must pass a specific perimeter determined by the Python package manager you’ve used. We’ve used PipEnv in our example below.
The following is a list of Python-supported package managers:
Package Managers Supported with CycloneDX Python
| Package Manager | clonedx-py Parameter | Locking / Pinning Capabilities | Notes | Baseline Used |
|---|---|---|---|---|
| Installed Packages | –environment | No | Avoid –environment usage, as the DevSecOps practitioner cannot trace and pin to an intentional package list | Generated by run |
| Poetry | –poetry | Yes | poetry.lock | |
| PipEnv | –pip | Yes | Distinguishes development requirement libraries | Pipfile.lock |
| Pip | –requirements | Yes | requirements.txt does not distinguish between development, text, and production deployments | requirements.txt |
SBOM Generation
To generate the SBOM in XML format, execute the following:
clonedx-py –pip –format json –force –o hardening-app.xml
The parameters cause the following execution:
–pip: use the PipEnv package manager
–format: output the report in json
–force: overwrite an existing report file if it exists
–o hardening-app.xml: outputs the SBOM to hardening-app.xml
Note: The choice of XML or JSON will depend on your Continuous Integration and Continuous Development (CI/CD) environment and ultimately the information’s consumer, which is likely to include change management, system security specialists (ISSO, ISSE, etc.) and supply chain oversight, where each consumer may require various artifact generations ranging from native formats (XML, JSON) for machine use, or Word documents for human review. For brevity’s sake, this article does not cover consumption cases, but will review a component example for clarification.
Component Review
Here is a snippet of the requests package used in a Python application, and is a common package used for web integrations and testing:
The first line of the output snippet shows that the component “requests” is a library. Other types of components include applications, containers, devices and so on. Other important lines in the snippet are the name, version, and trace (externalReferences). The additional lines provide supply chain details to assure delivery personnel identify signed versions of the requests library via signatures and version pinning. This is a simplified version focused on one dependency—requests—the actual SBOM contained 994 lines identifying all application components.
Agency Immediate Lift
By integrating supply chain risk management in the form of SBOM generation, you have earlier visibility into Zero Trust impacts as shown in the following table.
| Pillar | Function | Maturity Level | Benefit |
|---|---|---|---|
| Devices | Policy Enforcement & Compliance Monitoring | Advanced | Coverage:“…approve software and identify vulnerabilities and install patches” Impact: Reduces total lifecycle costs through earlier ID of vulnerabilities and policy issues. |
| Apps and Workloads | Secure App Dev & Deployment | Initial | Coverage: “…with formal code deployment mechanisms” Impact: Agency enables reporting much earlier in CI/CD processes. |
| Apps and Workloads | App Security Testing | Advanced | Coverage: “Agency integrates app security testing through the SDLC…” Impact: DevSecOp pipeline changes significantly lessen impact to availability. |
| Apps and Workloads | Visibility & Analysis Capability | Advanced | Coverage:“…security monitoring for most applications…” Impact: Policy updates to third-party patterns are easier to implement. |
T-Rex in Action – 2020 Census Technical Integration Effort: Team T-Rex supported development and deployment of DAS systems to apply formal differential privacy protections to survey data—protecting respondent privacy while maintaining statistical integrity.
The SBOM Python script used with DAS can be viewed here.
Summary
Agencies are seeking innovative ways to mature their Zero Trust posture. In this article, we have focused on improvements to your DevSecOps to increase maturity in two pillars: 1) Devices and Applications and 2) Workloads.
T-Rex’s cybersecurity engineers and architects work with Federal agencies to speed their Zero Trust endeavors through T-Rex’s Zero Trust Architecture Accelerator and innovative tooling as shown here. Contact us at cybersecurity@trexsolutionsllc.com to discuss how we can assist in your Zero Trust program.
Looking for additional articles on Zero Trust? Check out T-Rex’s Zero Trust articles:
twitter
