Generating code with AI is now very widespread; security review practices, however, have not caught up. Meanwhile AI-generated code still fails security checks more than a third of the time. So what do we do?
One way of dealing with this is to scale review speed with help from AI. However, this has to be part of a clearly structured review that doesn’t rely on vague prompts and that is properly reviewed by a human.
AI-Assisted Auditing Against OWASP ASVS
I’d like to share my experience using AI for security reviews. While developing the GameAP control panel, I used AI to conduct my own security audit against OWASP ASVS.
ASVS (Application Security Verification Standard) is an open standard that defines application security requirements. In practical terms, it is a well-defined, verifiable checklist containing hundreds of requirements that cover the full application development lifecycle.
The standard is straightforward to use: you work through the list, determine which requirements your application meets and which it does not, and implement whatever is missing. Here are a couple of examples:
“Verify that password change functionality requires the user’s current and new password.”
“Verify that the application checks compressed files (e.g., ZIP, GZ, DOCX, ODT) against the maximum allowed uncompressed size and the maximum number of files before extracting them.”
Each requirement is typically rooted in a real-world security incident.
The standard’s specificity, clarity, and structure make an ASVS-based audit a good fit for AI: instead of a vague prompt such as “find security issues,” each requirement gives the agent a precise line of inquiry.
For me, the standard was a real eye-opener, even though I had always taken security seriously and made a point of working through my own checklist of top vulnerabilities.
ASVS defines three verification levels, each reflecting the depth of the assessment and corresponding to a particular degree of application criticality. Each team decides which level its project should meet based on the project’s threat model and the potential impact of a compromise.
When I began a Level 1 self-assessment, I was surprised to find that I had overlooked several requirements: there was no rate limiting on authentication attempts; CORS was configured, but other HTTP security headers such as HSTS, CSP, and Referrer-Policy were missing; and MFA was not mandatory for administrator accounts.
The audit itself does not take very long, and AI makes it faster still: the agent handles the analysis, after which you review its findings, assess the results, and decide on the next steps.
In my case, AI agents did not always determine correctly whether a particular requirement had been met. Sometimes they marked a requirement as not met when it was actually not applicable to my project. The agent’s output therefore cannot serve as the final audit report; it is only a draft that must be reviewed. Once again, the final say in the audit rests with a human.
Know What You’re Actually Installing
Using AI for development means dependency security is especially important.
With slopsquatting in package registries and rug pulls in the MCP ecosystem, “check your dependencies” has become a job in its own right. Two practices have proven effective:
SCA (Software Composition Analysis). SCA tools continuously scan your dependency tree against databases of known vulnerabilities. Examples include Dependabot, Renovate, Snyk, npm audit, pip-audit, and OWASP Dependency-Check. These tools should run in CI, not depend on manual execution. Any critical-severity finding should fail the build. This automates the detection and handling of outdated dependency versions.
SBOM (Software Bill of Materials). An SBOM is a machine-readable inventory of every component in your build: direct and transitive dependencies, versions, licenses, and hashes. The standard practice is to generate it as a build artifact in CycloneDX or SPDX format. The value of an SBOM becomes clear the next time a critical vulnerability is disclosed in a popular library. The inventory lets you quickly determine whether your product is affected and whether you need to take action. Without it, you would have to investigate manually, which takes considerably longer.
Two additional measures are worth adding:
Check before installing, not after. If the model suggests a package you do not recognize, you can quickly check whether it exists in the registry, when it was published, how many downloads it has, whether its repository URL points to an actual source repository, and whether the maintainer has published other packages. Using a package published last week with 40 downloads and no source repository is closer to gambling than sound engineering.
Pin versions and verify integrity. Commit lockfiles with integrity hashes and verify package signatures wherever the ecosystem supports them. With these controls in place, a rug pull or any other dependency compromise will cause the build to fail closed rather than put your product at risk.
The bottom line
You can’t use AI output as the final audit report. It’s a draft that has to be reviewed by a human. But you can significantly scale review speed by using agents in your review structure.
Join our LinkedIn group Information Security Community!
——————————————————-
Click Here For The Original Source.
