Pre-Release Security Review for AI Code: Who Decides?

Summary: On VAON projects that follow our 10-step workflow, each version passes a security gate before release. Claude Code reviews every change in the version. A senior engineer reads each finding, separates real issues from false alarms, and decides whether to release or fix first. This gate sits on top of baseline checks that run on every project.

Contents

1. How is the pre-release gate different from checks on each pull request?
2. Why review the whole version when each pull request was already scanned?
3. What are the steps of the pre-release gate?
4. Who decides on release, and based on what?
5. How do the Japanese government notice and NIST SSDF relate?
6. When does the gate not run, or not suffice?
7. FAQ

1. How is the pre-release gate different from checks on each pull request?

VAON's pre-release security gate runs once per version, while the tier-1 checks run on every pull request.

Tier 1 also includes baseline rules on every project:

• the main branch is protected, so nothing merges without review;
• a company-managed Claude Code configuration (denied commands, sandbox, approved MCP servers);
• package names suggested by AI are checked before install, because AI can invent them;
• no real keys in development environments.

The pre-release gate is the last step of our Claude Code development workflow. How we configure Claude Code for the team is covered in rules for using Claude Code at work.

2. Why review the whole version when each pull request was already scanned?

The whole version is reviewed because some vulnerabilities only appear when changes combine, while each PR reviewer sees only one PR.

An illustration: the first PR adds an API that exports the customer list, with a permission check. Two weeks later, a second PR changes the shared permission function to fix another bug. Each PR makes sense. Together, the export API may open up to users who should not have access.

Automated scanners catch issues with a known signature, like a committed key or a vulnerable library. Business-level permission errors usually have none. According to the Claude Code docs, the /security-review command analyzes the changes on your current branch for vulnerabilities. Examples include injection, auth issues and data exposure.

3. What are the steps of the pre-release gate?

VAON's pre-release gate has five steps, and only the second is done by AI.

1. Set the scope. Identify every change between the previous version and the release candidate.
2. AI security review. Claude Code reviews those changes and lists suspicious points with location and reason.
3. A person reads every finding. A senior engineer checks each item against the code and the spec. Each is marked real, false alarm, or needs a question answered.
4. Decide. If a real item is unfixed, it is fixed and reviewed again before release.
5. Record. The conclusion for each item is kept with the release record.

The gate comes after three-layer review on each pull request, explained in three-layer pull request review for AI code.

4. Who decides on release, and based on what?

The release decision belongs to the project's senior engineer, not the AI. The AI only lists suspicious points. It does not know which data you publish on purpose, or which screen is only reachable on an internal network.

The table below is an illustration of how a person reads findings, not output from a real project:

One lesson from AI security review: false alarms are normal, so the value lies in the person reading results, not the length of the list. It is also not VAON's only security layer: our own infrastructure team also handles security testing. Our CTO and a Tech Lead are involved in every project, so a release decision always has an accountable name on it.

When a fix delays release or changes scope, the weekly report flags it under decisions needed from you.

5. How do the Japanese government notice and NIST SSDF relate?

VAON's pre-release gate references two documents. VAON uses them as a frame of reference and claims no certification against either.

First, a notice dated May 18, 2026 from Japan's National Cybersecurity Office (NCO) and the Ministry of Economy, Trade and Industry (METI). It was issued with Project YATA-Shield. Its first item asks software vendors to actively use highly capable AI before release, to reduce the chance of vulnerabilities being found after release. It names no tools and sets no standard.

Second, NIST SP 800-218 (SSDF, version 1.1, February 2022), a set of secure development practices that fit into any development model. What the Japanese notice asks of vendors is covered in AI coding security and the YATA-Shield notice.

6. When does the gate not run, or not suffice?

The gate has clear limits worth knowing for your project.

• You have not allowed code into AI tools. The AI steps do not run. The version still passes tier 1 and human code review.
• The project is not on the 10-step workflow. Tier 1 still runs on every pull request, but there is no version-wide review.
• The problem is outside the code. Server configuration and infrastructure design do not show up in a diff. They belong to security testing, scoped in the contract.
• After release. New vulnerabilities can be published after release day. Monitoring, patching and 24/7 coverage are agreed separately in the contract.

AI security review supports people and does not replace them. It raises false alarms and can miss things.

7. FAQ

Can /security-review replace penetration testing? No. The /security-review command reviews changed code; it does not attack a running system. VAON has its own infrastructure team, which also handles security testing. The scope of security testing for each project, and whether 24/7 monitoring is included, are agreed in the contract before work starts.

What happens when the AI raises many false alarms? False alarms are normal, so a person reads every result. A senior engineer checks each item against the code and spec, and records the reason when it is judged a false alarm. That reason saves debating the same item next time, and lets you see why it was dismissed.

If I do not allow my code into AI tools, what is still checked? Without your permission, VAON does not put your code into AI tools and the AI security review does not run. The version still passes the tier-1 checks on every project: secret scanning, dependency scanning and static analysis on every pull request. The main branch stays protected, and a human reviews before merge.

How does VAON use NIST SSDF and YATA-Shield? Our security process references NIST SP 800-218 (SSDF) and the May 18, 2026 notice from NCO and METI. We use them as a frame of reference and do not claim to meet either. The Japanese notice is a request with no certification to achieve, so VAON shows you a concrete process and records instead of a label.

Do you release with an unfixed security finding? A senior engineer decides whether to release or fix first, based on the conclusion for each item. Items judged to be real vulnerabilities are fixed and reviewed again before release. When a fix delays the release or changes scope, VAON tells you in the weekly report, under risks and decisions needed from you.

One thing you can do today: ask your development team about their last release. "Who read the security review results, and which items were judged false alarms, and why?" If the answer is "the tool was green", nobody decided.

To see how this gate would work on your project, book a free 60-minute consultation. Our CEO joins, you need no documents, and there is no commitment.