![[Security Architecture] Vulnerability Assessment](/uploads/2026/04/arch-intro-cat-security.png)
About this article
As the eighth installment (final) of the “Security Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains vulnerability assessment.
Vulnerability assessment is not a pre-release ceremony but continuous operation. The era of annual pentests is over - modern standard is automated inspection on every push built into CI/CD. This article covers the differences between SAST/DAST/SCA/IAST/pentests, CI/CD integration, and countermeasures against gaps in AI-generated code.
Before you read this
This article uses a good deal of security vocabulary — authentication, authorization, encryption. If that is unfamiliar, reading the primer "Security and Authentication" first makes it far easier to follow. You can also look anything up in the glossary as you read.
What is vulnerability assessment in the first place
Think of a health checkup. Even without symptoms, you get annual blood tests and X-rays to catch signs of disease early. Neglecting checkups because “I feel fine” can mean it’s too late by the time you notice.
Vulnerability assessment is a health checkup for your system. It’s the practice of inspecting source code, dependency libraries, running applications, and network configurations with automated tools and expert eyes, finding and fixing weaknesses before attackers exploit them.
Without vulnerability assessment, known vulnerabilities remain unpatched in production. Attackers check public vulnerability databases and automate attacks within hours — “we didn’t know” is no excuse.
Why vulnerability assessment is needed
First, because gaps get mixed into the code the AI writes. AI-driven dev raised productivity, but AI-written code is often security-naive, and human-only review can’t keep up. Building in automated assessment to let machines watch machines is the modern premise.
Second, because vulnerabilities in dependencies are surging. Modern apps depend on hundreds to thousands of libraries. Incidents like Log4Shell (the December 2021 Log4j zero-day) can happen tomorrow, and you’ll be hit by gaps in dependencies even with perfect own code.
Third, compliance. Certifications like SOC 2, ISMS (information security management system based on ISO 27001), PCI DSS require continuous vulnerability management. Not just form - the implementation record (when, what was inspected, how it was handled) becomes the audit target.
The main assessment methods — meant to be combined
Vulnerability assessment splits into multiple methods by “what to investigate, how.” None covers everything alone, so combination use is the premise.
| Method | Target | Timing |
|---|---|---|
| SAST | Source code (static) | At commit, in CI |
| DAST | Running app (dynamic) | Staging, production |
| SCA | Dependencies | At commit, daily |
| IAST | Inside running app | During test execution |
| Penetration testing | Comprehensive (manual) | 1-2x/year, before release |
| Bug bounty | External hunters | Continuous |
SAST — finding holes in the code by static analysis
SAST reads source code and looks for vulnerabilities without running it. Targets things detectable from code patterns - SQL injection, XSS (Cross-Site Scripting), hardcoded secrets. Modern standard usage: run on every push in CI, comment on PRs.
| Pros | Cons |
|---|---|
| Detect at commit time | Many false positives |
| Cover entire codebase | Misses runtime-only issues |
| Devs can fix immediately | Language/framework-dependent |
| Low learning cost | Can’t detect config mistakes |
Representative tools: Semgrep, Snyk Code, SonarQube, GitHub Code Scanning (CodeQL).
An area of high “just put it in” value. False positives appear, but preventing one critical gap pays off.
DAST — attacking the running application
DAST sends attack requests to actually-running apps and watches behavior. Common to run periodically against staging - the strength is checking behavior in the actual environment.
| Pros | Cons |
|---|---|
| Detect gaps in actual env | Slightly low coverage |
| Find config mistakes too | Long scan time |
| Language-independent | Test environment needed |
| Black-box possible | Login-required pages awkward |
Representative tools: OWASP ZAP, Burp Suite, StackHawk, AWS Inspector.
DAST is suited for staging. Run carefully on production, always with prior approval.
SCA — watching the dependencies
SCA checks whether dependencies have known vulnerabilities (CVE, Common Vulnerabilities and Exposures). Most vulnerabilities since 2024 originate in libraries, making SCA so important you could say SCA has higher ROI than self-written code.
| Pros | Cons |
|---|---|
| Detect vulnerable dependencies instantly | Updates may not catch up |
| Auto-fix PRs available | Need to inspect transitive deps |
| Detect license violations too | Old libraries get stuck |
| Extremely easy to deploy | Few false positives |
Representative tools: Dependabot (GitHub standard), Renovate, Snyk Open Source, Trivy.
The top-priority assessment to introduce. Dependabot is enabled with one config file.
The Equifax 2017 incident resulted from leaving an Apache Struts 2 patch (CVE-2017-5638) unpatched for 2 months, leaking about 147M people’s personal info, with settlements reaching about $700M (details in appendix “Critical Incident Cases”). It was a case showing the reality that even with not one line of own code vulnerable, one borrowed part can tilt a company - the case that decided SCA’s value.
IAST, RASP and penetration testing
IAST is a method where an in-app agent monitors behavior during test execution, combining the strengths of SAST and DAST. RASP operates in production to detect and auto-block attacks - positioned like an evolution of WAF.
| Method | Use case | Deployment difficulty |
|---|---|---|
| IAST | Precise detection during testing | Mid (agent-embedded) |
| RASP | Active defense in production | High (perf impact) |
Both need agents embedded in apps, with high deployment cost, but adoption spreads in serious large-enterprise operations.
Penetration testing sits at the other end of the scale.
A comprehensive assessment where specialists actually try attacks from the attacker’s view. The biggest value is finding combined gaps invisible to automated tools (business-logic flaws, authorization bugs, design issues), with going rates of pre-release, on major refactor, or annual periodic.
| Type | Content | Cost target |
|---|---|---|
| External black box | Attack from public face | $5k-20k |
| Internal (authenticated) | Attack after login | $10k-50k |
| Red team | Comprehensive org-wide drill | $50k+ |
| Source-included white box | Thorough check with code disclosed | $30k+ |
For vendor selection, presence of PCI QSA (PCI-certified security auditor) and OSCP (Offensive Security Certified Professional) holders is a guideline.
SBOM and the supply chain
SBOM is a list of all dependency components in an app. Since 2024, mandating has progressed in US government procurement, etc., and SBOM submission is becoming a transaction condition. Not just a tech requirement - a concept upgraded to a commercial requirement.
| Use case | Content |
|---|---|
| Impact investigation on vulnerability | Instantly identify if Log4Shell is in your org |
| Procurement/audit response | Submit to customers/regulators |
| License management | Grasp things like GPL inclusion |
| Supply-chain tracking | Record of “parts” origins |
SLSA (Supply-chain Levels for Software Artifacts) is a framework that levels build-pipeline reliability, becoming a wheel paired with SBOM in supply-chain security.
Three scenarios
If you are building solo or at a startup
Dependabot, GitHub Code Scanning (the free CodeQL tier) and Semgrep give you the minimum detection, and the cost is zero. Take it as modern common sense that Dependabot goes in unconditionally on day one. A penetration test can wait until an important customer asks for one, and npm audit or pip-audit is enough for an SBOM.
If you are a small or mid-size SaaS
Consolidate SAST and SCA into Snyk or GitHub Advanced Security, add StackHawk for DAST, and run a penetration test once a year. SOC 2 work makes continuous vulnerability management with records a hard requirement. An SBOM in CycloneDX format submitted to customers is the norm. On the organisational side, put one dedicated security person in place and run it as DevSecOps, with developers holding first-line responsibility.
If you are a large enterprise or in finance
A commercial SAST (Checkmarx, Veracode), DAST (Burp Pro) and the full set including IAST and RASP, plus quarterly penetration tests and an annual red-team exercise. SBOMs are generated automatically on every build, with SLSA Level 3 or above as the target. This is the world of a permanent CSIRT and SOC.
Response SLAs — the contest is decided by how fast you move afterwards
Vulnerability assessment is decided by post-discovery response speed. Below are industry-standard SLAs.
| Severity | Response deadline | Notification | Practical motion |
|---|---|---|---|
| Critical (RCE etc.) | Within 72 hours | Instant PagerDuty + Slack | Stop all work to respond |
| High | Within 1 week | Slack + create PR | Respond next sprint |
| Medium | Within 1 month | PR + Issue | Respond on plan |
| Low | Within 3 months | Issue | Respond on regular maintenance |
For assessment-integration timing, SCA (Dependabot) is enabled from day one, SAST is integrated into CI on PR, DAST runs weekly in staging, SBOM is auto-generated on all builds, and pentests are at least annual (regulated industries quarterly) - the practical rule. As shown by Equifax 2017, leaving Critical patches for 2 months becomes company-survival-level damage.
Critical is within 72 hours - the rule. Patch delays link directly to company-survival risk.
AI decision axes — Into an era where AI writes and AI watches
Why SAST is essential for detecting vulnerabilities in AI-generated code
As AI-written code volume increases, the probability of missing vulnerabilities with human review alone rises. AI especially prioritizes “making it work,” making insufficient input validation and omitted SQL parameter binding likely to slip in.
Embedding SAST tools like Semgrep and CodeQL in CI for automatic checking on every push is the minimum bar for AI-enabled development. An auto-fix loop where SAST-detected issues are handed back to AI for fixing → re-checked by SAST is also becoming practical.
SBOM makes AI-generated code dependencies visible
When delegating code generation to AI, dependencies on libraries humans aren’t aware of may be added. Cases where AI decides “lodash is handy for this” and instructs npm install, or adds pip install requests in Python.
With SBOM auto-generation mechanisms (CycloneDX, Syft, etc.), newly added dependency vulnerabilities can be detected immediately. In the AI era, dependency change frequency increases, making SBOM + SCA (Dependabot/Snyk) real-time monitoring even more important.
Pitfalls and forbidden moves
Here are the six most dangerous ways to have an accident in assessment operations. Every one has the structure of “installed” but not actually operated.
| Forbidden move | Why it is bad → what to do instead |
|---|---|
| Enabling Dependabot and leaving the alerts | 500 of them turn into wallpaper and the real Critical is buried → set an SLA and rotate ownership |
| Disabling SAST because of false positives | you lose the important detections along with them → tune the rules instead |
| One penetration test a year and no continuous assessment | holes in dependencies appear daily → switch to daily checks built into CI |
| Relying on a WAF instead of fixing the root cause | a WAF only stops the attacks it can detect → fix it in code, with parameterised queries and the like |
| Not generating an SBOM | a Log4Shell-class event leaves you unable to tell whether you are affected → generate one automatically on every build |
| Leaving vulnerability response to the security team | it never moves fast enough and the backlog piles up → run DevSecOps, with developers holding first-line responsibility |
Nor is it right to defer adoption on the grounds that “it is meaningless unless the tool is paid for.” Dependabot, Semgrep and OWASP ZAP together cover around 70 percent, and starting on the free tiers is the realistic move.
Author’s note - cases where both “patch delay” and “zero-day” became lethal
Cases where the cost of skimping vulnerability assessment tilted companies are perennial security-industry talking points.
The Equifax 2017 info-leak (Apache Struts 2 CVE-2017-5638 patch left for 2 months → 147M leaked → settlements about $700M) is the case that decided SCA’s (dependency assessment) value (details in appendix “Critical Incident Cases”).
Log4Shell 2021 (Log4j’s CVE-2021-44228) overnight exposed Java-built apps worldwide to a zero-day, frequently leaving organizations unable to even know if affected without SBOM - the trigger for supply-chain security (SBOM/SLSA) being baked into contract conditions.
Both left the lesson that “dependency gaps” are lethal, and own-code SAST/DAST alone can’t fully defend. The modern minimum line is inspecting daily-updated vulnerabilities daily. We’ve entered an era where the operation of humans looking once a year no longer holds.
What to decide - what is your project’s answer?
For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”
- SCA introduction (Dependabot / Renovate / Snyk)
- SAST introduction (Semgrep / CodeQL / SonarQube)
- DAST introduction (OWASP ZAP / StackHawk)
- SBOM-generation automation
- Pentest frequency and scope
- Vulnerability-response SLA (within how many days for Critical)
- AI security inspection (when LLM is used)
Related Articles
Summary
This article covered vulnerability assessment, including the use of SAST/DAST/SCA/IAST/pentests/SBOM, response SLAs, and new AI-era attack surfaces.
Enable Dependabot from day one, integrate SAST in CI, run DAST weekly in staging, auto-generate SBOM and define SLA. That is the practical answer for vulnerability assessment in 2026.
And this was the final installment of the “Security Architecture” category. Next time we’ll start a new category (Development and Operations Design).
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
Also popular with readers
📚 Series: Architecture Crash Course for the Generative-AI Era (59/95)