Automating Compliance - Why the SBOM Falls Short
Author: Cole Kennedy
Automating compliance, especially in high-risk environments has proven a difficult task. Tools such as Open Policy Agent and Cloud Custodian try to fill the gap by inspecting APIs and requests.
However, these tools do not have the data required to check if the application itself is in compliance. In order to know the compliance status of the actual artifact, we need to have trusted, structured data about the CI process itself.
Let's walk through a FedRAMP Compliance workstream to show where the pattern breaks down with existing tools focused on dependencies.
FedRAMP Container Compliance
Most readers will already know that FedRAMP (the Federal Risk and Authorization Management Program) is a U.S. Government-wide program that provides a standardized approach to security assessment, authorization, and Continuous Monitoring (ConMon) for cloud products and services. The FedRAMP Vulnerability Scanning Requirements for Containers bridges the vulnerability scanning compliance gaps between traditional cloud systems and containerized cloud systems.
The FedRAMP Vulnerability Scanning Requirements for Containers document calls out six compliance areas:
- Hardened Images
- Container Build, Test, and Orchestration Pipelines
- Vulnerability Scanning for Container Images
- Security Sensors (EDR)
- Registry Monitoring
- Asset Management and Inventory Reporting for Deployed Containers.
Most of these compliance requirement areas are shifted too far left, requiring data about security checks performed on artifacts and source code in earlier phases, data that are lost once the artifact leaves the CI system.
This timeline mismatch of security checks and compliance requirements causes security administrators to lose visibility into which artifacts are in compliance and which are not. This problem gets worse in large organizations with multiple security domains and interconnected CI systems.
Signatures Don’t Matter without Evidence
A good example of this mismatch lies in signature abuse.
When a software artifact moves from one domain to another we lose all of the evidence of the artifact going through a FedRAMP-compliant DevSecOps pipeline. Current solutions rely on verifying signatures of the source artifact.
In the aftermath of a major breach at NVIDIA, threat actors have been using stolen NVIDIA code signing certificates to make malware appear trustworthy. allowing malicious drivers to be loaded into Windows. Even though the certificates have expired, Windows still accepts the drivers signed using them.
In order to understand the risk or compliance of an artifact, we must be able to evaluate the evidence generated and used during the production of that artifact. The SBOM (Software Bill of Materials) is a tool used to communicate the ingredients of software to the consumers of that software. Implementation of the SBOM and related tooling will help reduce MTTR (Mean Time To Recovery) for incidents such as HeartBleed, and Log4J. It does not, however, help in cases where a supply chain is compromised, such as SolarWinds.
How the SBOM Falls Short
The CISA SBOM initiative is a great idea. It requires anyone selling software to the US Federal government to list the ingredients for that software in a machine-readable format (SPDX, CycloneDX). The SBOM mandate, however, does not cover providing information on whether an artifact met compliance requirements such as static application security testing (SAST), code test coverage, and two-party code review. An enterprise that wishes to automate and continuously monitor for FedRAMP compliance must also communicate that the artifact meets these compliance requirements.
Shift Left, Communicate Right
Enterprises that wish to remove out-of-band human checks must shift left, but also communicate right. Artifact metadata should be available for evaluation in the production environment as part of the Enterprise Asset Management system. Bringing this data into the production environment will allow administrators to fully understand the risk level of that software in a continuous manner.
TestifySec Witness
Automating compliance is why TestifySec built Witness. Witness automates the collection and verification of evidence in any environment, not just cloud, or Kubernetes. It solves the problem of communicating compliance data to system administrators, by
- Automating collection of meta-data during the build and testing process
- Automating “keyless” signing mechanisms
- Supporting storing and retrieving in a transparency log.
- Integrating with AWS, GCP, and GitLab
Witness is Open Source
Witness is an open-source project that can be integrated into any CI pipeline and release system. Witness currently supports integrations with the following platforms and tools:
- AWS
- GCP
- Git Meta Data
- GitLab
- Maven
- OCI Containers
- Sarif Data Format (SAST Testing)
The TestifySec team, partners and contributors to the Witness project are working hard to deliver additional tooling to help administrators communicate and automate compliance in real-time in any environment.
Please check out the Witness GitHub repository, reach out with questions or suggestions and/or contributions to the project.