[Security Architecture] Vulnerability Assessment

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.

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

Gaps mix into AI-written code

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.

Dependency vulnerabilities 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.

Required by 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.

Main assessment methods

Vulnerability assessment splits into multiple methods by “what to investigate, how.” None covers everything alone, so combination use is the premise.

SAST - find code gaps via 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.

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 - try attacks on the running app

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.

Representative tools: OWASP ZAP, Burp Suite, StackHawk, AWS Inspector.

DAST is suited for staging. Run carefully on production, always with prior approval.

SCA - watch over dependency vulnerabilities

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.

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 and RASP - monitor internals during execution

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.

Both need agents embedded in apps, with high deployment cost, but adoption spreads in serious large-enterprise operations.

Penetration testing - comprehensive assessment from attacker view

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.

For vendor selection, presence of PCI QSA (PCI-certified security auditor) and OSCP (Offensive Security Certified Professional) holders is a guideline.

SBOM and 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.

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.

Decision criterion 1: scale and phase

Assessment thickness is decided by public scope and data sensitivity.

At MVP stage, putting in IAST/RASP is excessive, but Dependabot is now common sense to put in unconditionally from day one.

Decision criterion 2: dev regime

Continuous vulnerability-assessment operation requires a regime. “Tools installed but no one’s looking” is meaningless.

The modern current is the DevSecOps thinking (uniting development, security, operations) where developers hold first-line responsibility for security. The model “security team looks at it later” can’t keep speed.

How to choose by case

Startup / personal dev

Dependabot + GitHub Code Scanning (CodeQL free tier) + OSS Semgrep. This alone gets minimum detection. Pentest when major customers demand it; SBOM is enough with npm audit or pip-audit.

B2B SaaS (growth)

Unify SAST/SCA with Snyk or GitHub Advanced Security, DAST with StackHawk, annual pentest. SOC 2 continuous monitoring becomes required, and the operation of leaving vulnerability-management records is set up. SBOM submission to customers in CycloneDX format is standard.

Enterprise / finance

Commercial SAST (Checkmarx, Veracode) + DAST (Burp Pro) + IAST (Contrast Security) + RASP. Quarterly pentests + annual red team drills. SBOM auto-generated on all builds, aim for SLSA Level 3+. CSIRT and SOC standing.

Vulnerability-response SLAs and phased practical matrix for assessment

Vulnerability assessment is decided by post-discovery response speed. Below are industry-standard SLAs.

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.

Vulnerability-assessment-operation pitfalls and forbidden moves

Typical accidents in assessment operation. All have the structure of “installed” but “not operating”.

The September 2017 Equifax info-leak (Apache Struts 2 CVE-2017-5638 patch left for 2 months, 147M leaked, settlements about $700M), the December 2021 Log4Shell (Java apps worldwide hit zero-day overnight, companies in droves not knowing if affected without SBOM) - cases where “dependency gaps” become lethal are repeated.

Vulnerability assessment is premised on operations of building into CI/CD for daily inspection. Annual pentest alone can’t seal gaps.

AI decision axes

1. Enable Dependabot from day one — SCA has the highest ROI
2. Integrate SAST in CI — automated inspection on every push is the modern minimum
3. Run DAST weekly in staging — seal gaps from config mistakes
4. Auto-generate SBOM and define vulnerability SLA — becoming a commercial requirement

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.

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

https://en.senkohome.com/arch-intro-security-network/ https://en.senkohome.com/arch-intro-security-secrets/ https://en.senkohome.com/arch-intro-security-auth/

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.