Application Security: Secure Development and Testing Practices

Application security (AppSec) encompasses the technical disciplines, process frameworks, and testing methodologies used to identify and remediate vulnerabilities in software before and after deployment. This page covers the professional scope of AppSec, the structured phases through which secure development operates, the regulatory bodies that define baseline requirements, and the boundaries distinguishing AppSec from adjacent cybersecurity domains. The sector spans web applications, mobile software, APIs, and embedded systems across both public and private organizations subject to US federal and state security mandates.

Definition and scope

Application security addresses vulnerabilities that arise within software itself — distinct from network-layer or infrastructure threats — and operates across the full software development lifecycle (SDLC). The NIST National Vulnerability Database (NVD) catalogs tens of thousands of Common Vulnerabilities and Exposures (CVEs) annually, with a significant proportion attributable to application-layer weaknesses rather than network or hardware flaws.

The formal classification of application-layer weaknesses is maintained by MITRE through the Common Weakness Enumeration (CWE) framework. The Open Web Application Security Project (OWASP) publishes the OWASP Top 10, which ranks the 10 most critical web application security risk categories and is referenced by the Federal Trade Commission, the Payment Card Industry Security Standards Council (PCI SSC), and federal agency acquisition guidelines.

Regulatory scope is broad. The Federal Information Security Modernization Act (FISMA) requires federal agencies and their contractors to implement application security controls aligned with NIST SP 800-53. The Payment Card Industry Data Security Standard (PCI DSS), maintained by PCI SSC, mandates secure development practices and application testing for any organization processing cardholder data. HIPAA (45 CFR Part 164) imposes technical safeguard requirements that extend to healthcare application software handling protected health information (PHI).

AppSec scope divides across three primary software categories:

• Web applications — browser-accessible software exposed to internet-facing attack surfaces
• Mobile applications — iOS and Android software subject to platform-specific threat models documented in the OWASP Mobile Security Testing Guide (MSTG)
• APIs — programmatic interfaces governed by the OWASP API Security Top 10, which is treated as a distinct risk surface from web application threats; see API security for deeper coverage

How it works

AppSec operates as a structured set of phases embedded within or alongside the SDLC. The NIST Secure Software Development Framework (SSDF), SP 800-218, defines a four-practice-group model that organizes AppSec activities:

1. Prepare the organization (PO) — Establish roles, security requirements, and tooling before development begins. This includes threat modeling, documented in NIST SP 800-154, which maps data flows and attack surfaces against assets at risk. Threat modeling is treated as a discrete professional specialty within the AppSec sector.

2. Protect software (PS) — Apply source code protections, access controls on development environments, and component integrity verification. This phase addresses supply chain risk through software composition analysis (SCA), which inventories open-source components against known CVEs. Supply chain security overlaps this phase directly.

3. Produce well-secured software (PW) — Implement secure coding standards (NIST, OWASP, or language-specific guidelines), conduct peer code reviews, perform static application security testing (SAST) and dynamic application security testing (DAST), and execute software composition analysis. SAST analyzes source code without executing it; DAST tests running applications by simulating external attacks. Interactive application security testing (IAST) instruments the application during runtime to combine both approaches.

4. Respond to vulnerabilities (RV) — Establish a vulnerability disclosure policy, triage findings by severity using the Common Vulnerability Scoring System (CVSS), and track remediation through a formal vulnerability management process.

DevsecOps integrates these four phases into continuous integration/continuous delivery (CI/CD) pipelines, automating SAST, DAST, and SCA at each code commit rather than at release gates alone.

Common scenarios

AppSec testing and remediation appear across five recurring operational scenarios:

• Pre-production security testing — SAST and SCA tools run within CI/CD pipelines before code is merged to production branches. DAST is applied in staging environments that mirror production configurations.
• Penetration testing of web applications — Credentialed and uncredentialed penetration testing of web applications follows methodologies such as the OWASP Web Security Testing Guide (WSTG). PCI DSS Requirement 6.4.1 mandates penetration testing of externally accessible application components at least annually and after significant changes.
• API security assessment — REST and GraphQL APIs are tested for broken object-level authorization, excessive data exposure, and injection vulnerabilities cataloged in the OWASP API Security Top 10. APIs often bypass perimeter controls that filter browser-based traffic, making them a priority assessment target.
• Third-party and open-source component review — SCA tooling identifies libraries with CVSS scores at or above 7.0 (classified as "High" severity under the CVSS v3.1 specification maintained by FIRST.org). Unpatched dependencies constitute a category of third-party risk management embedded within the software supply chain.
• Compliance-driven code review — FISMA-regulated agencies and PCI DSS-scoped organizations conduct AppSec reviews as a condition of authority-to-operate (ATO) approvals or qualified security assessor (QSA) audits respectively.

Decision boundaries

AppSec intersects with adjacent domains at defined boundaries that distinguish its scope from overlapping disciplines.

AppSec vs. network security — AppSec addresses vulnerabilities within application logic, authentication flows, session handling, and data processing. Network security fundamentals addresses transport-layer controls, firewall rules, and intrusion detection — neither substitutes for the other. An application with parameterized queries and output encoding remains vulnerable to network-layer attacks if perimeter controls fail, and vice versa.

AppSec vs. cloud security — Cloud security governs infrastructure configuration, identity federation, and platform controls. AppSec in cloud environments adds container image scanning, serverless function security review, and infrastructure-as-code (IaC) security analysis. These overlap in container and Kubernetes security, where both application runtime behavior and cluster configuration require assessment.

SAST vs. DAST — SAST identifies vulnerabilities in source code or bytecode without execution and integrates earliest in the SDLC. DAST requires a running application and detects runtime-dependent vulnerabilities such as authentication bypass, session fixation, and server-side request forgery that SAST cannot reliably detect. Neither method alone achieves comprehensive coverage; NIST SP 800-218 recommends combining both.

Practitioner qualifications — The application security workforce draws on certifications including the Certified Secure Software Lifecycle Professional (CSSLP), administered by (ISC)², and the Offensive Security Web Expert (OSWE), administered by Offensive Security. The cybersecurity certifications sector reference covers qualification standards across AppSec roles and adjacent disciplines.

Organizations subject to cybersecurity compliance requirements — including FISMA, PCI DSS, and HIPAA — face explicit AppSec obligations tied to named control families rather than general best-practice guidance, making AppSec a regulatory compliance function as much as a technical one.

References

• NIST Secure Software Development Framework (SSDF), SP 800-218
• NIST National Vulnerability Database (NVD)
• NIST SP 800-53, Security and Privacy Controls for Information Systems
• OWASP Top 10
• OWASP API Security Top 10
• OWASP Web Security Testing Guide (WSTG)
• OWASP Mobile Security Testing Guide (MSTG)
• MITRE Common Weakness Enumeration (CWE)
• FIRST.org — Common Vulnerability Scoring System (CVSS)
• PCI Security Standards Council — PCI DSS
• Federal Information Security Modernization Act (FISMA) — NIST overview
• CISA Known Exploited Vulnerabilities Catalog