3.5.3. Attack Surface Management and Secure Development
💡 First Principle: Attack surface management treats the organization's entire external footprint as a continuous discovery problem — because attackers are constantly discovering assets organizations have forgotten, and unknown assets get no security attention.
Attack Surface Management (ASM) covers the full lifecycle of external exposure:
Edge Discovery — Identifying all internet-facing assets: domains, subdomains, IP ranges, cloud-hosted applications, third-party services. Many organizations have forgotten about old domains, development servers, or cloud instances that are still running and accessible.
Passive Discovery — Using OSINT techniques to discover assets without touching them: certificate transparency logs (every certificate issued for your domains is public), DNS enumeration, Shodan/Censys searches for your IP ranges.
Security Controls Testing — Validating that controls are working as expected: are firewall rules actually blocking what they should? Are WAF rules triggering on known attack patterns?
Penetration Testing and Adversary Emulation — Authorized attack simulations testing real-world exploitability. A penetration test validates that a vulnerability is exploitable, not just present. Adversary emulation (red teaming) simulates specific threat actor TTPs against real defenses.
Bug Bounty Programs — Invite external security researchers to find and responsibly report vulnerabilities in exchange for rewards. Provides continuous testing by diverse talent beyond internal capabilities.
Secure Coding Best Practices:
| Practice | What It Prevents | Example |
|---|---|---|
| Input validation | Injection, overflow, unexpected behavior | Reject inputs not matching expected type/length/format |
| Output encoding | XSS | HTML-encode user content before rendering |
| Session management | Session hijacking, fixation | Regenerate session ID on auth; set Secure and HttpOnly flags |
| Authentication controls | Credential attacks | MFA, account lockout, PBKDF2/bcrypt for password storage |
| Data protection | Sensitive data exposure | Encrypt at rest and transit; mask in logs and UI |
| Parameterized queries | SQL injection | Use prepared statements; never concatenate SQL |
Secure SDLC (Software Development Life Cycle) integrates security at every phase: threat modeling during design, SAST during development, code review, DAST during testing, and ongoing vulnerability management post-deployment. Security is built in, not bolted on.
Threat Modeling — Structured analysis of a system to identify potential threats, their likelihood, and mitigations. STRIDE framework: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Performed during design to catch architectural flaws before they're built.
⚠️ Exam Trap: Penetration testing and vulnerability scanning are complementary, not interchangeable. Scanning identifies potential vulnerabilities at scale. Penetration testing validates exploitability of specific vulnerabilities in the context of your actual environment and defenses. Scanning first; pentest to validate the critical findings.
Software Assurance Maturity Model (SAMM)
SAST and DAST test code; OWASP SAMM measures the program that produces it. SAMM is an open framework that gives organizations a measurable way to analyze and improve their software security posture, and it is technology, process and organization agnostic.
| Business Function | Security Practices |
|---|---|
| Governance | Strategy & Metrics, Policy & Compliance, Education & Guidance |
| Design | Threat Assessment, Security Requirements, Secure Architecture |
| Implementation | Secure Build, Secure Deployment, Defect Management |
| Verification | Architecture Assessment, Requirements-driven Testing, Security Testing |
| Operations | Incident Management, Environment Management, Operational Management |
Each of the 15 practices has three maturity levels, with activities grouped into two streams. An organization scores its current level, sets targets, and improves in planned iterations.
⚠️ Exam Trap: The OWASP Top 10 is a list of web application risk categories; SAMM is a maturity model. "Assess how mature our secure development practices are and build a roadmap" → SAMM.
Third-Party Risk: Supply Chain, SCA, and SBOM
Most of an application's code is written by someone else. Three tools manage that supply chain risk:
| Tool | What It Answers |
|---|---|
| Software composition analysis (SCA) | "Which open-source and third-party components are in our software, and which have known vulnerabilities?" — run in the build or repository |
| Software bill of materials (SBOM) | "Where do we use library X?" — CISA defines an SBOM as a nested inventory, a list of ingredients that make up software components |
| VEX (Vulnerability Exploitability eXchange) | "Is this product actually affected?" — a supplier's (or other party's) statement of Not Affected, Affected, Fixed or Under Investigation for a specific vulnerability |
When a new CVE lands in a common library, SBOMs from your vendors and your own builds turn a search across every system into a lookup. SCA keeps your own dependencies current; requiring SBOMs (and VEX statements) from suppliers extends the same visibility to software you buy.
⚠️ Exam Trap: An SBOM lists components; it does not say whether a vulnerability in one of them is exploitable in the product. That is what VEX, or your own analysis, adds.
Shift-Left Security in the CI/CD Pipeline
Shift left means moving security checks earlier in the lifecycle, to where a defect is cheapest to fix: a developer corrects a flagged line in minutes, whereas the same flaw found in production needs change management, redeployment and possibly breach response and regulatory reporting. NIST SP 800-218 (the Secure Software Development Framework) builds this in through practices PW.7 (review and analyze human-readable code) and PW.8 (test executable code). Typical pipeline stages:
| Pipeline stage | Control | Catches |
|---|---|---|
| Commit / pull request | SAST; secret scanning; code review | Injection patterns, hard-coded credentials |
| Build | SCA; container image scanning | Vulnerable dependencies and base-image packages |
| Test / staging | DAST; API testing | Runtime and configuration flaws SAST cannot see |
| Gate | Fail the build when findings exceed a defined severity threshold | Stops known-bad code from deploying |
SAST does not fix code, does not catch every flaw, and does not replace DAST or penetration testing; it finds one class of problems earlier.
Secrets in source code. API keys, tokens and passwords committed to a repository (especially a public one) are exploitable as soon as they are seen, because possession of the key is all an attacker needs, so the risk is critical. A network vulnerability scanner assesses hosts and services, not source files, so it does not see them; secret-scanning tools and SAST do. Revoke and rotate the exposed credential first. Deleting it from the repository is not enough, because it stays in git history and may already have been copied.
Mobile application assessment. A mobile app needs more than one technique: SAST on the source, DAST against the running app and its back-end APIs, and mobile-specific tests for insecure local data storage, certificate validation (TLS and pinning) and inter-process communication (IPC) exposure. The OWASP MASVS and MASTG describe these tests. An app-store review is not a security assessment.
Reflection Question: During a red team exercise, an attacker discovers a forgotten subdomain dev-api.company.com running an old API version with a known authentication bypass. The domain was used during development 2 years ago and never decommissioned. Which attack surface management practice would have detected this before the red team did?
