SOX never mentions an SBOM or a dependency scanner. It asks for reliable internal control over financial reporting, and auditors usually examine IT general controls for the systems behind it. Change management, access control and build integrity are where software supply chain controls give them something to test.
What does the law actually require?
Section 404(a) of the Sarbanes-Oxley Act requires each annual report to include an internal control report. That report states management's responsibility for adequate internal controls and financial reporting procedures, and assesses their effectiveness as of the most recent fiscal year end. Section 404(b) requires the registered accounting firm to attest to and report on management's assessment.
The statute does not list IT controls. The practice around it does: auditors commonly test IT general controls, often organised with a framework such as COBIT, for systems that feed financial reporting. Confirm the scope with your own auditor, since it differs by company.
Which supply chain controls support the usual ITGC areas?
Change management. Auditors ask how code reaches production and who approved it. Pull request reviews, protected branches, signed pipeline runs and a ticket link for each release are direct evidence. A dependency update is a change too, so it belongs in the same trail.
Logical access. Who can modify the pipeline, publish packages or alter production configuration? Role lists, reviews and removal of leavers apply to build systems as much as to the app itself. Also include service accounts and tokens.
Operations and integrity. Is the artifact that ran in production the one that was reviewed? Reproducible builds, signed artifacts and an SBOM per release help show it. Backups and restore tests belong here as well.
Vendor and component risk. For software that touches financial data, a record of third party components and how vulnerabilities are handled shows a managed process, not a hope.
What does the evidence look like?
Auditors sample. They will pick a few changes from the year and ask you to show the request, review, approval, test and deployment for each. Make that trail easy to retrieve.
Good artifacts include dated scan results with closed tickets, branch protection settings exported on a schedule, access review sign offs, and release records that link an SBOM to a version. Safeguard's compliance automation can gather and map technical findings to control language. It does not make you SOX compliant and does not replace your auditor's view.
Where do teams fail?
Typical findings are developers who can push straight to production, shared accounts in build systems, emergency changes with no after the fact review, and exceptions that no one re-examines. Another is evidence with no timestamps, such as a screenshot taken the week before the audit.
What to do
- List the systems that feed financial reporting and the code that supports them.
- Ask your auditor which ITGC areas are in scope.
- Enforce reviews and branch protection on repositories for those systems.
- Restrict and review access to pipelines and package publishing.
- Generate an SBOM per release and link it to the change record.
- Define an emergency change process with a review after the fact.
- Export settings and logs on a schedule and store them with dates.
Quick check
Does SOX require an SBOM?
No. The law does not mention one. An SBOM can serve as evidence for change and component management if your auditor accepts it.
Can a tool make us SOX compliant?
No. Tools can collect and organise evidence. Management assesses controls, and the auditor attests to that assessment.
Sources
Last reviewed: 18 October 2026.
