Compliance reporting in software supply chain security is a recurring nightmare for most organizations. Every quarter, someone spends a week pulling data from six different tools, formatting it into spreadsheets, mapping it to framework controls, and hoping the auditor does not ask for something that was not captured. Then the auditor asks for exactly that, and the cycle repeats.
Safeguard's compliance reporting engine exists to eliminate this manual work. It continuously collects evidence from your development pipeline and maps it to regulatory framework controls, generating audit-ready documents on demand.
The Evidence Collection Problem
Before we get into how Safeguard solves this, it is worth understanding why compliance reporting is painful. The data that auditors need is scattered across multiple systems:
- Vulnerability management data lives in your scanner
- SBOM records live in your SBOM generation tool
- Policy enforcement records live in your CI/CD system
- Remediation timelines live in your issue tracker
- Access control records live in your identity provider
- Change management records live in your source control platform
Each of these systems has its own data format, API, and retention policy. Stitching them together into a coherent narrative that satisfies an auditor is a manual, error-prone process.
Safeguard addresses this by serving as the central point of integration. Because it connects to your source control, CI/CD, issue tracker, and identity provider, it captures evidence continuously and stores it in a format that is already mapped to compliance frameworks.
Supported Frameworks
Safeguard provides pre-built report templates for the following frameworks:
SOC 2 Type II
The SOC 2 report maps Safeguard data to Trust Services Criteria, focusing on:
- CC6.1 (Logical Access): Evidence of role-based access control to security tools and source code
- CC7.1 (System Monitoring): Continuous vulnerability monitoring and alerting evidence
- CC7.2 (Anomaly Detection): Detection of supply chain anomalies including dependency confusion and typosquatting
- CC8.1 (Change Management): Policy gate enforcement on all code changes, with audit trails
ISO 27001
The ISO 27001 report maps to Annex A controls:
- A.8.9 (Configuration Management): SBOM generation and dependency tracking evidence
- A.8.28 (Secure Coding): Vulnerability scanning and remediation evidence
- A.5.19 (Supplier Relationships): Vendor security assessment records
- A.8.8 (Technical Vulnerability Management): Vulnerability triage and remediation SLA compliance
NIST SSDF (SP 800-218)
The NIST Secure Software Development Framework report maps to practices and tasks:
- PO.1 (Security Requirements): Policy definition and enforcement evidence
- PS.1 (Protect Software): Source code access control and integrity verification
- PW.4 (Reuse Secure Software): Dependency vetting and SBOM management
- RV.1 (Vulnerability Response): Vulnerability identification, triage, and remediation records
Additional Frameworks
Safeguard also supports PCI DSS (Requirement 6), FedRAMP, HIPAA (Technical Safeguards), and the EU Cyber Resilience Act. Custom framework mappings can be defined for industry-specific requirements.
Generating a Report
The reporting workflow has three steps: configure, preview, and export.
Configuration
Select the framework, time period, and scope. Scope can be the entire organization, a specific business unit, a team, or individual projects. For recurring reports, set a schedule (weekly, monthly, or quarterly) and a distribution list.
The configuration also lets you define which evidence types to include. For a first audit, you probably want everything. For subsequent audits, you can focus on changes since the last report.
Preview
The preview shows you exactly what the auditor will see, with your live data populated. This is where you catch gaps. If a control has no evidence mapped to it, the preview highlights it in red and suggests actions to close the gap.
Common gaps include:
- No SBOM for a project in scope: Generate the SBOM before exporting the report
- Missing remediation records: Ensure vulnerability triage decisions are recorded in the portal, not just in Slack conversations
- No policy enforcement on a project: Add the project to an existing policy or create a new one
Export
Reports export as PDF, HTML, or structured JSON. The PDF format is designed for auditors who want a traditional document. The HTML format includes interactive elements like expandable evidence sections and linked references. The JSON format is for organizations that feed compliance data into GRC platforms.
Each export includes a cryptographic hash for integrity verification. If an auditor questions whether a report has been modified after generation, the hash provides proof of authenticity.
Evidence Artifacts
The reports are backed by detailed evidence artifacts that auditors can drill into. These include:
SBOM snapshots: Point-in-time records of every component in every project, with version numbers, licenses, and provenance data.
Vulnerability timelines: For each vulnerability, a complete timeline from discovery to resolution, including triage decisions, remediation actions, and verification.
Policy evaluation logs: Every CI/CD pipeline evaluation, showing which policies were checked, whether they passed or failed, and what action was taken.
Access control records: Who has access to which projects and tools, when access was granted or revoked, and by whom.
Change records: Every dependency change, with the pull request that introduced it, the review that approved it, and the SBOM that captured it.
These artifacts are retained according to your configured retention policy. For most compliance frameworks, a minimum of one year of historical data is recommended.
Gap Analysis
The gap analysis feature is useful between audits. It continuously evaluates your current state against the framework requirements and shows you where you fall short. This turns compliance from a periodic scramble into a continuous process.
The gap analysis dashboard shows:
- Coverage percentage for each framework (how many controls have evidence)
- Trend over time (are you improving or regressing?)
- Priority gaps ranked by audit risk (controls that auditors most commonly flag)
- Recommended actions to close each gap
Custom Metrics and KPIs
Beyond framework-specific reports, Safeguard supports custom compliance metrics:
- Mean time to remediation by severity level
- Vulnerability escape rate (vulnerabilities that reach production)
- SBOM accuracy (how well SBOMs match actual deployed dependencies)
- Policy exception count and aging (how many exceptions exist and for how long)
These metrics can be added to any report template and tracked on a dedicated compliance dashboard.
Working With Auditors
A practical tip: give your auditor read-only access to the Safeguard portal. Most auditors spend significant time requesting evidence, waiting for responses, and asking follow-up questions. Portal access lets them explore the data directly, ask more precise questions, and complete the audit faster.
The auditor role in Safeguard provides read-only access to reports, evidence artifacts, policy configurations, and audit logs. It does not expose source code, vulnerability details beyond what is in the reports, or internal team communications.
How Safeguard.sh Helps
Safeguard.sh eliminates the manual work of compliance reporting by continuously collecting evidence from your development pipeline and mapping it to framework controls. Reports that used to take a week of manual assembly are generated in minutes, with full evidence artifacts and gap analysis included. The continuous gap analysis ensures you are always audit-ready, not scrambling at audit time. For organizations subject to multiple frameworks, the ability to generate reports from the same underlying data set, mapped to different controls, turns compliance from a cost center into a managed process.