SOC 2 code scanning evidence, and what it covers for ISO 27001

Every SOC 2 audit gets to the same question about engineering: show me that changes to the software were reviewed before they reached production. ISO 27001 asks a close cousin: show me that you develop securely and test what you build. Teams usually answer with screenshots of a pull request, a scanner dashboard and a spreadsheet stitched together the week before fieldwork. SOC 2 code scanning evidence is better when it comes from the scan itself, already mapped to the controls.

This post covers what the two frameworks actually ask for, which parts of that a code scanner can honestly support, and which parts it cannot. Then it shows the evidence Vulkro Core produces. One point up front: a scanner does not make anyone compliant, and neither SOC 2 nor ISO 27001 is something a tool can grant.

What do SOC 2 auditors ask for under CC8.1?

SOC 2 reports are built on the AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022). Two of the Common Criteria touch code directly:

• CC8.1, change management. The entity authorises, designs, develops or acquires, configures, documents, tests, approves and implements changes to infrastructure, data, software and procedures. In an audit that becomes a sample: the auditor picks changes from the period and asks for the evidence that each one was reviewed, tested and approved before deployment.
• CC7.1, detection. The entity uses detection and monitoring to find configuration changes that introduce vulnerabilities, and susceptibility to newly discovered ones. For a software company that includes vulnerable dependencies.

Two facts shape the evidence. First, a SOC 2 report is an attestation by an independent CPA firm, not a certificate: the report describes your controls and the auditor's opinion of them. Second, a Type II report covers a period, often six to twelve months. A control that started halfway through has a gap the auditor will note. Evidence that is produced on every change, automatically, has no such gap.

Which ISO 27001:2022 controls cover secure development?

The 2022 revision of ISO/IEC 27001 gathers secure development into a run of Annex A controls, with implementation guidance in ISO/IEC 27002:2022:

Control	Name
A.8.25	Secure development life cycle
A.8.26	Application security requirements
A.8.27	Secure system architecture and engineering principles
A.8.28	Secure coding
A.8.29	Security testing in development and acceptance

Two neighbours matter too: A.8.8, management of technical vulnerabilities, and A.8.32, change management. Unlike SOC 2, ISO 27001 does lead to a certificate, issued by an accredited certification body after auditing your management system. Again, a tool is evidence for that audit, not a substitute for it.

What evidence can a code scanner honestly provide?

Map the questions to what a scan actually observes, and the honest list is shorter than many tool brochures suggest.

What a scan can show:

• That a security review of the code ran on a given change, at a given time, against a given commit (CC8.1, A.8.25, A.8.29).
• What that review found: injection, broken access control, hardcoded secrets, weak cryptography, each with a file and a line (A.8.28).
• Which dependencies carry known vulnerabilities, and whether your code reaches the vulnerable function (CC7.1, A.8.8).
• That a new finding blocked a merge, and that the finding later disappeared because the code changed.
• A history of all of the above across the audit period.

What a scan cannot show:

• That a human approved the change, or that the approver was not the author. That lives in your version control and ticketing.
• That requirements were defined before building (most of A.8.26), or that the architecture is sound (A.8.27).
• That developers were trained, that a penetration test happened, or that production was configured as reviewed.
• That code with no findings is secure. No findings means no detector fired, not that the code is safe.

A tool that claims to "cover" A.8.27 or the approval half of CC8.1 is overstating. The useful thing a scanner can do is be precise about the half it does cover, and say plainly when it has no evidence either way.

What does good scanner evidence look like?

The evidence an auditor can use has three properties: it is tied to a change, it is dated, and it is the same every time you run it. A dashboard screenshot has none of those. A file written by the CI job that ran on the change has all three.

The cheapest way to get there is to make the scan part of the merge itself. With Vulkro Core, a CI step on every pull request looks like this:

# fail the pull request only on findings that are new against main
vulkro gate --base origin/main --format sarif > vulkro-gate.sarif

# keep a dated record of the scan for the audit period
vulkro scan . --save

vulkro gate scans both the working tree and the base, and exits 1 only on findings the change introduced, so existing debt does not block every merge. The SARIF file attaches to the pull request. --save stores each scan with its timestamp in a local database, and vulkro history lists them, which is the record an auditor asks for when they want to know what was true on a given date.

How do you map findings to SOC 2 and ISO 27001 controls?

Two commands turn the scan into control language.

# control-by-control status in the terminal
vulkro compliance . --profile soc2
vulkro compliance . --profile iso27001

# a folder of evidence for the auditor
vulkro compliance-pack . --framework soc2-full -o soc2-evidence/
vulkro compliance-pack . --framework iso27001 -o iso-evidence/

vulkro compliance maps each finding to every control it affects. Under the soc2 profile, for example, an unauthenticated endpoint counts against CC6.1, a vulnerable package against CC7.2, and a route that appeared or disappeared between scans raises a warning on CC8.1. Under iso27001, a CVE match in an installed package fails A.8.8 and code weaknesses map to A.8.28. A control that no finding maps to is reported as not evaluated, never as a pass: the scan has no evidence either way, and the report says so.

vulkro compliance-pack writes the files an auditor can keep: a manifest, a summary, a findings CSV with file and line, and one file per control. The soc2-full framework covers the full Trust Services Criteria from CC1.1 to CC9.2, and adds an HTML table that lists, for each control, the rule IDs that support it and the ones that contradict it. A control fails on a High or Critical finding and is partial with only Medium or Low ones. vulkro report . --profile soc2 renders the same evaluation as an HTML report for readers who will not open a CSV.

For Salesforce orgs, Vulkro Cloud computes SOC 2 and ISO 27001 status per org from its open issues and exports evidence packs as PDF and CSV, each with a SHA-256 checksum. The compliance evidence use case shows both.

A checklist before fieldwork

• A security scan runs on every change to the main branch, and the result is stored with the change.
• New High and Critical findings block a merge, and exceptions are recorded with a reason.
• Scan history covers the whole audit period, not just the last month.
• Dependency vulnerabilities are tracked to a fix or a recorded decision.
• The evidence pack names its framework, its scan and its date.
• Process controls (approvals, training, threat modelling) have their own evidence, because the scan does not provide it.

If your customers are in Europe, the same evidence feeds other regimes. We cover the Cyber Resilience Act and NIS2 and DORA for Salesforce orgs separately.

Where to see it

The compliance evidence use case shows the control view. The SOC 2 reference, the compliance overview and the compliance-pack reference list every profile and framework. To build a pack from your own repository, start here.

Frequently asked questions

Does SOC 2 require code scanning?

No criterion names a specific tool. CC8.1 asks that changes be tested and approved before release, and CC7.1 asks that you detect vulnerabilities, so an automated scan on every change is one of the most direct ways to evidence both. Auditors care that the control operates consistently across the period.

Which ISO 27001 control covers secure coding?

A.8.28, secure coding, in the 2022 revision of Annex A. It sits alongside A.8.25 (secure development life cycle), A.8.26 (application security requirements), A.8.27 (secure architecture) and A.8.29 (security testing in development and acceptance).

Can a scanner make us SOC 2 compliant or ISO 27001 certified?

No. A SOC 2 report is an independent auditor's opinion, and ISO 27001 certification comes from an accredited certification body. A scanner produces evidence for the technical part of some controls; Vulkro's packs describe themselves as evidence, not attestation.

What counts as evidence for CC8.1?

For each sampled change, auditors look for a record that it was reviewed, tested, approved and deployed as approved. A scan result tied to the commit covers the automated security review and testing part. The approval and deployment records come from your version control and release tooling.