Regulated industries

The evidence an audit asks for, produced where the code already is.

Regulated teams are asked to prove two things at once: that the code handling regulated data was reviewed before it shipped, and that reviewing it did not hand a copy to somebody new. Most review tools can only answer the first by failing the second. This page is the shared argument behind the healthcare, financial services and legal pages: what an assessor asks for, what comes out of a scan, and where the line falls between evidence and compliance.

Start the 14-day trial Deployment inside your perimeter →

Runs on your own machines
Per-control evidence pack
Software bill of materials
Air-gapped deployment

01 / What an auditor asks for

Seven questions, and what actually answers them

Frameworks differ in vocabulary far more than in substance. Underneath the clause numbering, an assessor looking at application code is asking the same short list in every regulated sector.

Seven questions an assessor asks about application code, and the artifact or property that answers each one.
The question	What answers it
Show the code was reviewed before it shipped	A review of the exact version that went out, with the issues it raised and what happened to each one. The date and the version matter as much as the result.
Show what the product is made of	An inventory of the components you ship, built from the versions your build actually resolved rather than the ranges your manifests ask for, in a format a reviewer can read with a tool.
Show which known vulnerabilities matter	A per-advisory statement: affected, not affected with the reason, or still under investigation. An inventory without this turns into a spreadsheet nobody can close.
Show the review happens again	Two reviews that can be compared, and a release check that fails a build on new high-risk issues. A single review, run once, answers a question nobody asked.
Show it control by control	The findings arranged against the control identifiers of the framework being assessed, so the reviewer reads their own numbering instead of translating yours.
Show where regulated data travels in the code	The places sensitive fields reach logs, URLs, exports and outside services. This is the question an assessor asks in every regulated sector, with a different noun in it each time.
Show the review did not create a new exposure	Who held a copy of the code while it was being reviewed, and under what agreement. A review tool that takes a copy adds a party to every answer above.

Summarised in plain language from the frameworks mapped in the next section. Which questions your assessor asks, and which controls are in scope, depends on the framework and on your organisation: the binding text is the framework itself, and this is the subset a review of source code can produce an artifact for.

The last row is the one that decides which tools a regulated team can use at all. Every other answer gets longer if the review itself moved a copy of the code somewhere.

02 / What one scan produces

Five artifacts, written on your own machine

Each of these is a file a reviewer can open, diff and archive. None of them is a dashboard reading you are asked to take on trust, and none of them is produced by uploading anything.

Findings that cite a file and a line: Every issue names the file, the line and the path the data took to get there. An assessor can open the file and check the claim, and an engineer can fix it without a second conversation. Where the scanner cannot establish a path, it says so rather than presenting a guess as evidence.
A component inventory: A software bill of materials in the two formats reviewers ask for, built from resolved versions and matched against a vulnerability database that lives on your disk. The database arrives as a checksummed file, so a machine with no route out still checks dependencies against current advisories. How the inventory is built.
An exploitability statement: For each advisory against a component you ship: affected, not affected with the reason recorded, or under investigation. Not affected is claimed only where the analysis found no route into the vulnerable code, and where no claim can be made the status stays open rather than quietly resolving in your favour.
A per-control evidence pack: A directory, one file per control, each citing the findings and the endpoints it was built from, with a summary an assessor can read first and a flat table of every finding against every control. It is generated on your machine, which means it can be diffed, archived and opened on a review machine with no network.
A result that can be compared to the last one: The same code, the same version of the scanner and the same settings produce the same result in the same order. That is what makes two reviews comparable, so a regular review leaves behind a difference rather than a recollection.

vulkro cra-bundle . --framework soc2-fullexit 1, findings present

cra-readiness.zip/built on this machine
- index.htmlreadiness one-pager
- compliance/soc2-full, 61 controls
  - manifest.jsonframework, scan id, control summary
  - summary.mdevery control with its status
  - findings.csvfinding to control mapping, flat
  - soc2-full.htmlper-control evidence table
  - controls/one file per control
    - CC6.1.jsonPass
    - CC6.6.jsonPartial, 2 findings
    - CC7.2.jsonFail, 1 finding
    - CC8.1.jsonPass
    - P4.1.jsonPass
    - ...56 more control files
  - README.mdwhat each file is, and what it is not
- sbom/
  - cyclonedx.jsonCycloneDX 1.6
  - spdx.jsonSPDX 2.3
- vex/
  - openvex.jsonOpenVEX 0.2.0, per CVE

$ vulkro compliance-pack . --framework soc2-full --output ./compliance/

vulkro cra-bundle runs the same pack and writes it into one zip with the SBOM and VEX documents beside it. Every file is generated locally: nothing is uploaded, and each control file cites the findings and endpoints it was built from.

The evidence pack as it lands on disk: a summary, a flat finding-to-control table, and one file per control naming what it was built from.

The pack is a set of files rather than a signed report. That is deliberate: files can be opened on a review machine with no network, compared against the previous quarter, and kept under your own retention policy.

03 / Frameworks

Which frameworks are mapped, and how deep each one goes

Two levels, and the difference matters at audit time. A category map tells you where your gaps are. A per-control map gives the assessor a row for each control with the evidence for and against it.

The compliance frameworks the scanner maps findings onto, the depth of each mapping, and what each one produces.
Framework	Depth	What the mapping gives you
PCI DSS 4.0	Per control	About thirty controls across Requirements 6, 11 and 12, each with its published title, a plain statement of what it requires, and the findings that support or contradict it. A control-by-control page is written alongside the files.
NIST SP 800-53 Rev. 5	Per control	The moderate baseline across the access control, audit, configuration management, identification, risk assessment and system integrity families, with the same per-control page.
SOC 2 Trust Service Criteria	Per control	The full criteria set, CC1.1 through CC9.2, for a readiness review that has to be walked one criterion at a time.
SOC 2 and ISO/IEC 27001:2022 Annex A	By category	Findings fan out from their category to the controls that category bears on. The right level for knowing where the gaps are before an audit starts, and not a substitute for the auditor deciding what each control needs.
HIPAA Security Rule	By category	The same category mapping, with the health-data findings carrying the Security Rule paragraph they bear on.
GDPR	Evaluation	An Article 32 evaluation of security of processing. Separately, a record-of-processing document in the Article 30 shape is rendered from the data-flow lineage the scan builds. The two are different outputs and are not interchangeable.
EU Cyber Resilience Act	Readiness bundle	The inventory, the exploitability statement and an evidence pack stapled into one archive with a readiness one-pager. Framed as readiness evidence rather than a conformance attestation.

Source: the framework tables compiled into the scanner. PCI DSS 4.0 is cited from the Payment Card Industry Data Security Standard v4.0 (March 2022), NIST SP 800-53 from Rev. 5, the SOC 2 criteria from the 2017 Trust Service Criteria as revised in 2022, and the HIPAA rows from 45 CFR Part 164. Evaluation profiles for OWASP ASVS, the CIS Controls, the CWE Top 25 and the NIST secure software development framework are available in the same run.

Which framework applies to you is not a question a scanner can answer. What it can do is stop you translating a finding list into somebody else’s numbering by hand at eleven at night, which is where the errors come from.

04 / Where it runs

None of this requires sending your code anywhere

The reason a regulated team ends up reading this page is usually the same: the review tool they were offered wanted a copy of the code, and the code describes the regulated data.

Source is read from disk, the analysis is built in memory, findings are written to a local database, and every document described above is rendered from that run. There is no upload step, no broker and no processing service in the middle, because there is nothing on the far side to process anything. One line leaves a normal installation and it carries an entitlement check: which product, which install, which version, which operating system family, a timestamp, and how many scans have run since the last call. There is no field for a file name, a project name or a finding to travel in.

That collapses several conversations at once. There is no source code transfer for a data processing agreement to describe, no vendor environment to place in or out of your assessment scope, and no third-party retention period to ask about, because the reports and the evidence packs are files on your own infrastructure. Your security review of us is a review of a binary that reads local files.

A closed network goes one step further. An air-gapped installation carries its entitlement in a signed licence file on disk and makes no network call at all, and the vulnerability database arrives as a checksummed file you move in on whatever schedule your process allows.

trust boundaryone switch closes it

Everything the scan needs stays on your machine: the code it reads, the map it builds of how your product fits together, the findings it writes, and the optional local model it can consult without leaving the machine. One line leaves.

Stays on this machine: source code, call graph + taint, findings, account layer, and the local model on 127.0.0.1
One crossing: A signed entitlement check and a usage counter, on a debounced cadence.
Never crosses: source code, file paths, file names, finding contents, project names, the hardware fingerprint

The scan pipeline never touches the wire. In an air-gapped installation the single crossing is closed too, and entitlement is carried by a licence file on disk.

The binding data-handling commitment is in the privacy policy.

05 / By industry

What changes from sector to sector

The argument above is the same everywhere. What changes is the regulated noun, the questions the assessor opens with, and which failure shapes in the code carry the consequence.

Healthcare and HIPAA

Patient data has an identifier list attached to it, and the review is built around that list: where health fields rest unencrypted, where identifiers reach logs and URLs, and which outside services receive them.

Fintech and PCI DSS

The assessment turns on scope. A review that runs where the code already sits does not add a system to the environment you have to describe, and the output is written in the clause numbering your assessor reads.

Legal technology and confidentiality

A firm cannot hand client material to an outside service, and the code that runs a matter system describes the matter boundary in detail. Nothing is uploaded, so the due-diligence answer stays short.

Regulated work that runs on Salesforce

Health Cloud, Financial Services Cloud, the org settings behind them and the data bridged out of them are reviewed by Vulkro for Salesforce, which is the same review pointed at a Salesforce build.

Defence and closed networks

A machine with no route out runs on a licence file on disk and makes no network call at all. The vulnerability database is carried in as a checksummed file on whatever schedule your process allows.

EU Cyber Resilience Act

The obligations that attach to placing software on the EU market, split into the parts a tool can produce an artifact for and the parts that are an organisational process.

06 / Honest scope

Evidence is not compliance, and a clean result is not proof

A compliance page that lets a reader believe a tool closed an obligation it never touched has done them real harm. This section is the boundary, written as data.

Start with the evidence itself. The scanner is measured against an independent test of real applications with publicly documented vulnerabilities, and the result is published in full including what it misses.

47 of 83

Real vulnerabilities found

Measured against vulkro 0.18.0 on 2026-07-18.

False alarms in the same run

Raised in a reviewed file where no documented vulnerability sits.

Vulnerabilities it did not find

They stay in the test rather than being removed, which is why the first figure is not higher.

Every vulnerability in this test is a real, publicly documented bug in a real application, confirmed by reading the code at that exact version. The ones Vulkro cannot find stay in the test rather than being removed. The full result and how it was measured.

What the compliance output does not do, what each limit means in practice, and the reason for it.
What it does not do	What that means	Why
It is not a certification	The output is evidence. It is not an attestation, an opinion or a report on compliance, and nobody signs it on your behalf.	Certification is a procedure carried out by people who are qualified to carry it out. The pack says so on its own front page, before a reader reaches a single finding.
It does not cover people, process or premises	Training records, change approval, key ceremonies, physical access and the agreements you hold with your own vendors are not scanner output.	Most frameworks are mostly organisational. The evidence pack sits beside those records in a file rather than standing in for them, and a control with no code-level signal is reported as having none.
It does not decide your scope	Nothing in the output determines which systems are in scope, which framework applies, or which controls you have to meet.	That is a determination about your organisation, made against the framework with people qualified to make it. A scan can only describe the code it was pointed at.
A clean result is not proof of absence	No finding in a file means nothing was matched there, not that nothing is wrong there.	The accuracy page publishes what the scanner finds, what it misses, and the classes it is weakest on, so the boundary around a clean result is a published figure rather than an assurance.
It does not read anything at runtime	Nothing is executed and no running system is touched. Deployment posture, live infrastructure and behaviour under load are outside what a review of source code sees.	The scan reads the code and the artifacts in your repository. It is not a penetration test and it is not a monitoring product.
The evidence covers what was parsed	A language with no parser is counted and skipped, and a dependency in a manifest format that is not read is absent from the inventory.	Absence is reported as unread rather than as clean, which is the only honest way to hand an incomplete inventory to a reviewer.

Source: the evidence pack states the same boundary on its own front page, and the maintained limits reference is kept beside the detector documentation.

One engine, so one evidence rule

Vulkro reviews your codebase and Vulkro for Salesforce reviews your Salesforce build. Vulkro Red is the other half of the team: it takes what the review found and works out what an attacker would do with it. They share one engine, which is why a finding that cannot cite a file and a line is not printed by any of them, and why the evidence pack reads the same whichever review produced the findings.

The reviewVulkro

Reviews your code

Goes through every line of your codebase before a release, the way a senior engineer would if they had the time, and tells you what a customer could exploit.

You get: what to fix, and a pass or fail on the releaseWhat it checks

Vulkro for Salesforce

Reviews your Salesforce build

The same review for the part of your business that runs on Salesforce, including the settings in the org itself, and what the AppExchange security review will ask you for.

You get: a straight answer on whether you are ready to submitVulkro for Salesforce

The red teamVulkro RedComing soon

Attacks what they found

Takes the review and works out what an attacker would actually do with it: which small problems chain together into a real break-in, and which ones are noise.

You get: the attack, step by step, before someone else runs itHow it works

One engine behind all three, so the red team works from what the review already foundIt all runs on your machine. Your code never leaves it.