A successful build does not show that an app is safe to release. Before launch, review it as you would code from an unfamiliar contributor: map the data and trust boundaries, run broad automated checks, trace the critical paths by hand, and record what still needs fixing or escalation. Treat one afternoon as a practical triage window—not a certification or a guarantee that you will find every flaw.
Start by deciding what could cause the most harm
Before opening a scanner, sketch the app’s important assets and paths: what data it handles, what actions users can take, which routes are public, where data is stored, and which identity providers or third-party services are involved. Include AI models, agents, and tools if the app uses them. Mark where untrusted input enters and where authority or data crosses a boundary, such as browser to API, app to database, repository to coding agent, or CI to deployment. Threat modeling is one of the verification techniques in NISTIR 8397.
As an Amazon Associate I earn from qualifying purchases.
Use these questions to decide where to spend review effort. They are a practical way to rank risk, not a formal scoring formula from OWASP or NIST.
| Review dimension | Ask | Signals for closer attention |
|---|---|---|
| Exposure | Can an unauthenticated person reach this route or component? | Public routes, endpoints, or services that were added or exposed for deployment |
| Data sensitivity | What information passes through or is stored here? | Credentials, personal data, payment data, or regulated information |
| Privilege | Whose authority does this code use? | Service, agent, CI, or deployment identities with broad permissions |
| Trust boundary | Where does untrusted content enter, or does authority change? | Browser/API, app/database, app/provider, repository/agent, and CI/deployment boundaries |
| Blast radius | How much could one failure affect? | All tenants or production infrastructure rather than one record |
Run broad checks before reading code line by line
Automated checks can quickly surface known vulnerable packages, suspicious secrets, and recognizable coding patterns. They cannot establish that the app is secure or determine whether its business rules are correct. AI-assisted work deserves the same or greater scrutiny as work from an unknown contributor: generated code can omit authorization or input validation, and generated package choices may be outdated or hallucinated. OWASP’s Secure Coding with AI Cheat Sheet discusses these review concerns.
#1 Best Overall
- Inspect the dependency manifest and lockfile. Check that each newly added package is the intended package, necessary, and checked for known vulnerabilities. Look for unexpected names or additions that the app does not appear to need.
- Run the available language-appropriate static and secret checks. Review findings rather than treating a clean scan as proof; scanners only identify issues their rules and inputs can detect.
- Inspect configuration and deployment definitions. Look for changes that affect public exposure, permissions, credentials, or what code runs during build and release.
- Read the important findings in context. Confirm whether a warning reaches sensitive data or a privileged action, and record the relevant path or configuration for follow-up.
NISTIR 8397’s verification menu includes static code scanning, heuristic secret detection, built-in checks, black-box and structural test cases, historical test cases, fuzzing, web-application scanning when applicable, and attention to included libraries, packages, and services. It is a menu of techniques, not a requirement to run every technique on every small app. OWASP’s Secure Code Review Cheat Sheet also treats tools as aids to, not substitutes for, review.
Trace the paths attackers or ordinary users can exercise
Follow each critical action from its entry point through the code that performs it and the data it touches. Focus on behavior, not only whether a file contains a security-related function.
Authentication and sessions
- Follow credential handling, session creation, storage, and invalidation.
- Check whether sensitive actions require re-authentication where appropriate.
- Do not treat a logged-in state as authorization for every action.
Authorization for each route and object
- For every protected route, identify the server-side check that permits the specific user to perform the specific function.
- For object access, verify that the check applies to the requested object—not merely that the caller has an account or is signed in.
- Pay particular attention to actions that read, change, or delete another user’s data.
Input, output, and data handling
- Trace external input at its boundary. Check validation, parameterized queries, and output encoding for the context where content is rendered.
- Follow user-controlled values used in paths, URLs, templates, commands, or deserialized data; check that each is constrained for its use.
- Check whether credentials, tokens, or personal data can appear in source, logs, or error messages. Keep secrets out of project files and contexts that an AI tool can read.
These checks reflect the common review focus on authentication, authorization, and input handling in OWASP’s Secure Code Review guidance. A scanner may flag a pattern, but only tracing the app’s actual flow can show whether an access check protects the right object or whether sensitive data reaches a log.
Free tools Windows power users keep installed
One-click scans. No signup required.
Inspect the AI agent and the delivery path
The risk may lie outside generated application code. A coding agent can encounter untrusted repository or network content, run tools with broad permissions, or gain access to credentials. Generated changes can also alter how code is built, tested, or deployed. OWASP’s IDE and AI-Assisted Development Security guidance treats the development setup as part of the security boundary.
Rank #3
- Review changes to package scripts, CI workflows, Dockerfiles, build and release scripts, agent instructions, hooks, and tool configuration.
- Look for new network access, downloaded or executed external code, secret forwarding, broadened permissions, and automatic approval of agent actions.
- Check whether repository instructions, external content, and connected tools are treated as untrusted input rather than as trusted commands.
- Confirm that the agent has only the credentials, network access, permissions, and tools needed for its task.
Turn findings into a release decision
Write down each issue with enough evidence for someone else to reproduce or verify it. Include the affected route, object, dependency, configuration, or workflow; the possible impact; who owns the fix; and what retest will show it is resolved. A useful finding describes a concrete path to harm, not just a scanner alert.
- Block release or escalate unresolved high-risk problems involving authentication, authorization, exposed secrets, unexpected public access, or a compromised build or deployment path.
- Assign and retest issues with a clear owner and a defined verification step before treating them as resolved.
- Require informed approval. A human reviewer who understands the code should approve it; a successful compile or clean automated scan is not that approval.
If the reviewer cannot explain what a critical path does or why its access check is sufficient, the path has not been meaningfully reviewed. Keep the written outcome honest about what was inspected and what remains unresolved.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use standards to extend the review, not to claim a pass
NISTIR 8397, by Paul Black, Vadim Okun, and Barbara Guttman, was published by NIST in 2021. Its broad set of developer-verification techniques can help identify additional checks that fit the app, including testing, scanning, fuzzing, and threat modeling. It does not establish that a one-afternoon review is sufficient for a particular application.
If the app itself includes AI or machine-learning features, OWASP’s Artificial Intelligence Security Verification Standard (AISVS) 1.0, released in June 2026, adds AI-specific requirements. OWASP describes it as 191 requirements across 12 chapters and three appendices, with verification levels 1, 2, and 3. Its topics include model supply chains, output control, vector database security, agent orchestration, MCP security, adversarial robustness, monitoring, and AI-assisted coding controls. AISVS is intended to complement—not replace—checks of general application, infrastructure, and supply-chain security.
Best Value
There is no reliable prevalence statistic here that supports a blanket claim about what percentage of AI-built apps contain vulnerabilities. The practical case for careful review is simpler: generated code still needs to be understood, and working software can still mishandle access, input, secrets, dependencies, or deployment.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
