Application Security: Secure Development and Testing Practices

Application security (AppSec) covers the technical practices, process frameworks, and regulatory obligations governing how software is built, tested, and maintained to resist exploitation. This page describes the structure of the AppSec service sector — including the major testing disciplines, the standards bodies that define practice expectations, and the conditions that determine which approaches apply in a given development environment. The sector spans both internal development programs and externally contracted security services across commercial, government, and critical infrastructure contexts.

Definition and scope

Application security addresses vulnerabilities introduced at the code, architecture, dependency, and configuration levels of software systems. The Open Worldwide Application Security Project (OWASP) publishes the OWASP Top 10 — a widely referenced classification of the most critical web application security risks — which documents categories including injection flaws, broken access control, and cryptographic failures as the dominant failure patterns in production applications.

NIST defines application security controls within NIST SP 800-53, Rev 5 under the System and Communications Protection (SC) and System and Information Integrity (SI) control families. Federal agencies subject to the Federal Information Security Modernization Act (FISMA) are required to apply these controls when authorizing software systems that process, store, or transmit federal information.

The scope of AppSec practice divides along two structural axes:

• Development-phase security — practices embedded within the software development life cycle (SDLC), including threat modeling, secure code review, and security requirements analysis
• Testing-phase security — activities conducted against completed or near-complete builds, including static analysis, dynamic analysis, penetration testing, and dependency scanning

Both axes apply to first-party code (software built internally) and third-party code (open-source libraries and commercial components), the latter governed in part by NIST SP 800-161, which addresses supply chain risk management.

Professionals operating in this sector hold certifications from bodies including (ISC)², which offers the Certified Secure Software Lifecycle Professional (CSSLP), and GIAC, which offers the GIAC Web Application Penetration Tester (GWAPT) credential.

How it works

AppSec programs are structured around a secure SDLC framework. The NIST Secure Software Development Framework (SSDF), SP 800-218, organizes secure development into four practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV).

A standard AppSec program operates through five sequential phases:

1. Requirements and design — Security requirements are defined alongside functional requirements. Threat modeling — using structured methods such as STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) — identifies attack surfaces at the architecture stage before a single line of code is written.

2. Secure coding — Developers apply language-specific secure coding standards. CERT Secure Coding Standards, published by the Software Engineering Institute at Carnegie Mellon University, provide language-level guidance for C, C++, Java, and Android environments.

3. Static Application Security Testing (SAST) — Automated tools analyze source code or compiled binaries without executing the program. SAST identifies insecure patterns such as buffer overflows, hard-coded credentials, and SQL injection sinks at the code level. Contrast: SAST operates without a running environment, making it effective early in the pipeline but unable to detect runtime configuration errors.

4. Dynamic Application Security Testing (DAST) — The application is tested in a running state against simulated attack inputs. DAST identifies issues invisible to SAST, including authentication bypass, session management flaws, and server misconfiguration. The distinction between SAST and DAST is directly addressed in the OWASP Testing Guide v4.2, which is the primary reference document for web application test methodology.

5. Penetration testing and remediation — Human testers perform goal-oriented exploitation attempts to validate whether discovered vulnerabilities are exploitable in chained attack sequences. Findings are classified by severity — Critical, High, Medium, Low — using the Common Vulnerability Scoring System (CVSS), maintained by NIST's National Vulnerability Database.

Common scenarios

AppSec practices apply across four primary deployment contexts, each carrying distinct regulatory and technical requirements:

Financial services applications — Under the Gramm-Leach-Bliley Act (GLBA) Safeguards Rule (16 C.F.R. Part 314), covered financial institutions are required to implement application-level controls as part of a comprehensive information security program. The Federal Financial Institutions Examination Council (FFIEC) provides supplemental guidance on application security testing expectations for banks and credit unions.

Healthcare software — Applications that process electronic protected health information (ePHI) are governed by the HIPAA Security Rule (45 C.F.R. §§ 164.302–318), which requires covered entities to implement technical safeguards including audit controls and transmission security. HHS's Office for Civil Rights (OCR) has issued guidance treating application vulnerabilities as potential HIPAA Security Rule violations.

Federal and defense contractors — Organizations seeking FedRAMP authorization for cloud-based applications must satisfy the FedRAMP Security Controls Baseline, which incorporates NIST SP 800-53 Rev 5 controls and requires independent third-party assessments (3PAOs). Defense contractors handling Controlled Unclassified Information (CUI) face additional requirements under the Cybersecurity Maturity Model Certification (CMMC) framework administered by the Department of Defense.

Payment systems — Applications that store, process, or transmit cardholder data must satisfy the Payment Card Industry Data Security Standard (PCI DSS), currently at version 4.0 as of 2022, which mandates application security testing requirements including penetration testing at least once every 12 months and after significant infrastructure changes (PCI Security Standards Council).

The Information Security Providers maintained on this reference network document AppSec service providers and frameworks organized by these deployment contexts.

Decision boundaries

Choosing the appropriate AppSec approach depends on three primary variables: the software's regulatory classification, the deployment stage, and whether the code base is first-party or third-party.

SAST versus DAST is determined by pipeline position. SAST integrates into pre-commit and CI/CD pipelines, returning findings before deployment. DAST requires a testable runtime environment and is most applicable in staging or pre-production. Interactive Application Security Testing (IAST) — a hybrid approach — instruments the running application from within, capturing runtime data during functional testing and providing higher signal fidelity than either standalone method. IAST tools require agent-level access to the application stack and are not applicable to black-box testing engagements.

Penetration testing scope is governed by whether the engagement is classified as a black-box, grey-box, or white-box assessment. Black-box engagements simulate an external adversary with no prior knowledge; white-box engagements provide testers with full source code and architecture documentation, consistent with the methodology described in NIST SP 800-115, the primary federal reference for technical security testing.

Software Composition Analysis (SCA) applies specifically to third-party and open-source dependencies. SCA tools map declared and transitive dependencies against known vulnerability databases (NVD, OSV). Following the 2021 Executive Order 14028 on Improving the Nation's Cybersecurity, federal agencies and their software suppliers are required to produce a Software Bill of Materials (SBOM) — a machine-readable inventory of software components — with NTIA-defined minimum elements documented at NTIA SBOM resources.

The determination of whether an application requires a full third-party penetration test versus internal SAST/DAST coverage is typically driven by the data classification level, applicable compliance framework, and the organization's risk acceptance threshold as documented in its formal risk management process under NIST Risk Management Framework (SP 800-37).

Practitioners and researchers navigating this sector can consult the Information Security Providers for categorized service and framework entries, or review the for guidance on how this reference network is organized.