CIS Control 16 Application Software Security Guide

Most organisations that build software run some scanning, yet few can show an assessor a documented development process, a component inventory with risk and support status, and proof that every in-house application was tested. CIS Control 16 (Application Software Security) in CIS Controls v8.1 covers the security life cycle of software that an organisation develops, hosts or acquires. This guide sets out its 14 Safeguards by Implementation Group, what each one actually asks for, an implementation sequence, the evidence the CIS Controls Assessment Specification measures, and how the Control maps to NIST, ISO and OWASP frameworks. It is written for application security leads, engineering managers and GRC staff preparing for a CIS assessment. It does not repeat general application security practice: for testing tools, pipeline placement and programme design, see the Application Security Guide.

Key takeaways

There is no IG1 Safeguard in Control 16. Safeguards 16.1 to 16.11 start at IG2 and 16.12 to 16.14 (code-level checks, application penetration testing, threat modelling) are IG3 only, so an IG1 organisation meets Control 16 through vendor choice and Controls 2, 4 and 7.
Four Safeguards are documents with a 12-month clock. The assessment specification fails 16.1, 16.2 and 16.6 outright if the process has not been reviewed or updated within twelve months, so review dates are evidence.
The component inventory is the backbone. Safeguard 16.4 asks for a bill of materials that records the risk of each third-party component and whether it is still supported, evaluated at least monthly; 16.5 is then measured against it.
Coverage is counted per application. For 16.12 and 16.13 the specification counts in-house applications with and without static analysis, dynamic analysis and penetration testing, and authenticated testing is expected for critical applications.
Secrets and pipeline identities are where Control 16 meets NHI risk. Leaked tokens in commits, over-scoped CI credentials and shared production secrets in test environments undermine 16.8, 16.10 and 16.11 even when scanning is in place.

What it is and who it applies to

CIS describes Control 16 as managing the security life cycle of in-house developed, hosted or acquired software to prevent, detect and remediate security weaknesses before they can impact the enterprise. It applies to any organisation that writes code, including scripts, infrastructure as code, low-code workflows and integrations, and to organisations that host or heavily configure acquired software.

IG1: no Control 16 Safeguards. Small organisations that only buy software still need Control 2 (software inventory), Control 4 (secure configuration) and Control 7 (patching); choosing suppliers with a published vulnerability disclosure process and support lifecycle is the practical IG1 contribution.
IG2: Safeguards 16.1 to 16.11: process, vulnerability handling, root cause analysis, component inventory and trust, severity rating, hardened application infrastructure, environment separation, developer training, secure design and vetted security modules.
IG3: adds 16.12 (static and dynamic analysis), 16.13 (application penetration testing) and 16.14 (threat modelling), which need specialist skills and tooling.

CIS Controls v8.1 (June 2024) clarified Safeguard wording, revised asset classes, added a Govern security function and realigned mappings to NIST CSF 2.0; CIS states no Implementation Group assignments changed. The Safeguard numbers and titles below match the CIS Controls Assessment Specification, which was written for v8. Take asset class and security function values from the v8.1 spreadsheet if you report them formally.

Structure and key requirements

Safeguard	Title	IG	What it requires
16.1	Establish and Maintain a Secure Application Development Process	IG2, IG3	Documented process covering secure design standards, secure coding practices, developer training, vulnerability management, security of third-party code and security testing procedures; reviewed annually or on significant change
16.2	Establish and Maintain a Process to Accept and Address Software Vulnerabilities	IG2, IG3	A way for external parties to report vulnerabilities, a named responsible party, intake, assignment, remediation and remediation testing, a tracking system with severity ratings and timing metrics; reviewed annually
16.3	Perform Root Cause Analysis on Security Vulnerabilities	IG2, IG3	Evaluate the underlying issues that create vulnerabilities, so teams fix classes of flaw rather than individual bugs
16.4	Establish and Manage an Inventory of Third-Party Software Components	IG2, IG3	A bill of materials of components in use and slated for use, with the risk each poses; evaluated at least monthly for changes and continued support
16.5	Use Up-to-Date and Trusted Third-Party Software Components	IG2, IG3	Established frameworks and libraries, acquired from trusted sources or evaluated for vulnerabilities before use
16.6	Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities	IG2, IG3	A rating system that orders fixes and sets a minimum level of security acceptability for release; reviewed annually
16.7	Use Standard Hardening Configuration Templates for Application Infrastructure	IG2, IG3	Industry-recommended hardening for servers, databases, web servers, containers, PaaS and SaaS components; in-house code must not weaken it
16.8	Separate Production and Non-Production Systems	IG2, IG3	Separate environments for production and non-production
16.9	Train Developers in Application Security Concepts and Secure Coding	IG2, IG3	Role and environment specific secure coding training for all development personnel, at least annually
16.10	Apply Secure Design Principles in Application Architectures	IG2, IG3	Least privilege, complete mediation, input validation for size, type and range, minimised attack surface, default accounts removed or renamed
16.11	Leverage Vetted Modules or Services for Application Security Components	IG2, IG3	Platform or vetted services for identity, encryption, and audit logging; only standardised, extensively reviewed encryption algorithms
16.12	Implement Code-Level Security Checks	IG3	Static and dynamic analysis within the application life cycle
16.13	Conduct Application Penetration Testing	IG3	Manual testing as authenticated and unauthenticated users; authenticated testing for critical applications to find business logic flaws
16.14	Conduct Threat Modeling	IG3	Structured design review of entry points and access levels by trained individuals, before code is written

How to read the requirements

16.2 needs an external front door: the Safeguard explicitly includes a means for external entities to report. RFC 9116 security.txt at /.well-known/security.txt, with the required Contact and Expires fields and a Policy link to your disclosure policy, is the simplest evidence. See the Bug Bounty and Vulnerability Disclosure Guide.
16.6 is a release gate, not only a triage scale: the "minimum level of security acceptability" means a written rule such as "no open critical or high findings in internet-facing code without an approved exception". CVSS can be the base, adjusted for exposure and data sensitivity. See the CVSS v4 Guide.
16.4 and 16.5 cover what you build with, not only what you deploy: Control 2 inventories installed software; 16.4 inventories libraries, frameworks, base images and build plugins inside your applications, including those planned for use. An SBOM generated per build in CycloneDX or SPDX is the usual vehicle. See the SBOM Guide.
"Trusted" in 16.5 includes the publisher: the XZ Utils backdoor (CVE-2024-3094, versions 5.6.0 and 5.6.1) shipped malicious code in release tarballs that differed from the reviewed git source, after the attacker spent about two years gaining release rights. Trust decisions should consider maintainer health and build provenance, not just the absence of known CVEs.
16.7 extends Control 4 to the application stack: CIS Benchmarks or vendor baselines for the web server, database, container runtime and managed services the application runs on. See the Container Image Security Guide.

Identity and NHI requirements

Control 16 does not name identities, but several Safeguards fail in practice because of how code, pipelines and applications handle credentials.

Secrets out of source (16.1, 16.10): the secure coding standard should forbid credentials in code, configuration and container images, require retrieval from a secrets manager at run time, and run secrets scanning with push protection. In the Sourcegraph breach, a site-admin token committed on 14 July 2023 went unflagged by automated analysis and was abused 47 days later. Exposed secrets must be revoked, not only deleted from history. See the Secrets Management Guide.
Environment separation includes identities (16.8): separate accounts, subscriptions or projects are not enough if test and production share service accounts, API keys or signing keys. Use distinct workload identities per environment and block production credentials from non-production networks. See the OWASP NHI Top 10 NHI8 Environment Isolation Guide.
Vetted identity modules (16.11): use the platform identity provider, standard OAuth 2.0 and OpenID Connect libraries and managed workload identity rather than custom token handling or home-grown encryption. The specification counts security components that contain custom code where a vetted alternative exists.
Pipeline credentials: CI/CD service accounts, deploy keys and package-publishing tokens can change production code. Scope them per repository, prefer short-lived federated credentials over stored tokens, and protect release rights with more than one approver. ATT&CK T1195.002 Compromise Software Supply Chain and T1552.001 Credentials In Files describe what these controls prevent. See the CI/CD Pipeline Identity Security Guide.
Scanner and test credentials (16.12, 16.13): authenticated DAST and penetration testing need test accounts. Create dedicated, non-production or low-privilege test identities, time-bound them to the engagement and disable them afterwards.

Implementation steps

Scope the estate: list in-house developed applications, hosted and heavily customised acquired applications, and their owners, criticality and exposure. The specification draws the 16.12 to 16.14 counts from the authorised software inventory (Control 2), so add a "developed in-house" and "critical" attribute there.
Write the development process (16.1) and severity system (16.6): cover the six components the specification checks, define severity bands and the release acceptability rule, set an annual review date and record approval. Align it with NIST SP 800-218 (SSDF) practice groups so it also serves customer and regulator questions. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.
Open the vulnerability intake (16.2): publish security.txt and a disclosure policy, name the responsible team, and route reports into the same tracker as internal findings with severity and timing fields (identified, analysed, remediated).
Build the component inventory (16.4, 16.5): generate an SBOM per build, record for each component its risk (known vulnerabilities, licence, maintainer health) and support status, and run a monthly review. Add a software composition analysis gate that blocks new components with critical known vulnerabilities or no support. Start in report-only mode for a few sprints, then block on new findings only, so the backlog does not stop releases.
Harden and separate (16.7, 16.8): apply hardening baselines to the application stack through infrastructure as code, check for drift, and confirm every production system has a non-production counterpart with separate credentials and data masking.
Train and design (16.9, 16.10, 16.11): run annual role-specific training (web, mobile, infrastructure as code), publish secure design principles and an approved list of security modules, and use security champions to spread them. See the Security Champions Programme Guide.
Close the loop (16.3): categorise confirmed vulnerabilities by CWE, run root cause analysis on critical findings and on any class that recurs, and feed lessons into the standard, training and design patterns.
Add IG3 depth (16.12 to 16.14): run SAST on every in-house codebase and DAST on every deployed web application or API, commission authenticated penetration tests for critical applications, and require a threat model for new systems and significant design changes. See the Threat Modelling Guide.

Rollback and tuning: every new gate should have a documented bypass with approval and expiry, so a false positive does not block an urgent fix. Track bypasses as exceptions under 16.6.

Small versus large organisations

Small development teams (IG2): use the security features of your code hosting platform (dependency alerts, secrets scanning, code scanning) to cover 16.4, 16.5 and much of 16.12 cheaply, keep the 16.1 process to a few pages, and use security.txt with a shared mailbox for 16.2.
Large or regulated estates (IG3): the challenge is coverage and consistency across hundreds of repositories. Enforce controls through shared pipeline templates, report coverage per business unit, and use an ASPM or equivalent to deduplicate findings. See the Application Security Posture Management (ASPM) Guide.

Evidence and assessment

The CIS Controls Assessment Specification scores Control 16 through document checks, counts of applications and components, and timeframes.

Safeguard	Evidence an assessor expects	Measure in the specification
16.1	Approved secure development process with version history	Exists; count of the six required components; fails if over 12 months since review
16.2	Disclosure policy, security.txt or reporting page, tracker with severity and timing fields	Exists; components present (reporting, responsible party, intake, assignment, remediation, testing); fails over 12 months
16.3	Root cause analysis procedure and completed analyses	Vulnerabilities with and without root cause analysis
16.4	SBOMs or component register with risk and support status, monthly review records	Components with complete versus missing information; time since last review
16.5	SCA reports, approved repositories and package sources	Components up to date, and up to date and trusted
16.6	Severity rating scheme and release acceptability rule	Exists; components present; fails over 12 months
16.7	Hardening baselines and configuration scan results for application infrastructure	Components meeting versus not meeting standards
16.8	Environment diagram and asset inventory showing paired environments	Production systems with and without a non-production counterpart
16.9	Training records per developer, course content by role	Personnel with completed and in-scope training
16.10, 16.11	Secure design principles in the process, architecture reviews, approved module list	Components with design principles applied; security components with custom code
16.12	SAST and DAST configuration and recent results per application	In-house software verified, and not verified, by static and by dynamic analysis
16.13	Penetration testing process, reports, retest evidence	Process exists; applications tested unauthenticated; critical applications tested authenticated
16.14	Threat modelling process and models per application	Process exists; in-house applications with and without a threat model

Metrics that show it is working

Testing coverage: percentage of in-house applications with SAST, SCA and secrets scanning, and of deployed web applications with DAST, weighted by criticality.
Component health: percentage of components with known critical vulnerabilities or no vendor support, and time to upgrade after a critical advisory.
Time to remediate: median days from report or detection to verified fix per severity band, including externally reported vulnerabilities from 16.2.
Recurrence: repeat findings of the same CWE in the same codebase, which shows whether 16.3 root cause analysis changes anything.
Secrets exposure: secrets detected in commits per month and median time to revoke.

For detection, monitor the techniques the Control reduces: T1190 Exploit Public-Facing Application through web application firewall and application logs, and T1195.001 Compromise Software Dependencies and Development Tools through SCA alerts on newly introduced or modified packages.

Mapping to other frameworks

Safeguards	NIST CSF 2.0	NIST SP 800-53 Rev 5	ISO/IEC 27001:2022 Annex A
16.1, 16.6	PR.PS-06	SA-3, SA-15	A.8.25 Secure development life cycle
16.2, 16.3	ID.RA-01, ID.RA-08	RA-5(11), SI-2	A.8.8 Management of technical vulnerabilities
16.4, 16.5	ID.RA-01, PR.PS-06	SR-3, SR-4, SR-11, SA-22	A.8.30 Outsourced development, A.5.21
16.7	PR.PS-01	CM-2, CM-7	A.8.9 Configuration management
16.8	PR.IR-01	CM-4(1)	A.8.31 Separation of development, test and production environments
16.9	PR.PS-06	AT-3, SA-16	A.8.28 Secure coding
16.10, 16.11, 16.14	PR.PS-06	SA-8, SA-17, SA-11(2), SC-13	A.8.26, A.8.27 Secure system architecture and engineering principles
16.12, 16.13	ID.RA-01	SA-11, SA-11(1), SA-11(8), SA-15(7)	A.8.29 Security testing in development and acceptance

NIST SP 800-218 (SSDF version 1.1) is the closest companion framework: 16.1 and 16.9 sit in its Prepare the Organization practices, 16.10 and 16.12 in Produce Well-Secured Software, and 16.2 and 16.3 in Respond to Vulnerabilities. OWASP SAMM 2.0 offers a maturity view across its five business functions (Governance, Design, Implementation, Verification, Operations), and OWASP ASVS 5.0 gives testable requirements for 16.10 and 16.13. See the OWASP ASVS Guide. Use the official CIS v8.1 mappings for formal crosswalks.

Common pitfalls

Scanning without a process: tools are running but there is no approved 16.1 document or 16.6 severity scheme, so the Safeguards fail at the first measure. Write and date the documents first.
An SBOM nobody reads: SBOMs are generated per build but no one records risk or support status or reviews them monthly, which is what 16.4 measures. Assign an owner and review cadence.
Deleting leaked secrets instead of revoking them: history rewrites leave the credential valid, as the Sourcegraph case shows. Treat every detected secret as compromised.
Shared credentials across environments: separate environments with the same service account or API key turn a test compromise into a production one, defeating 16.8.
Penetration testing only the login page: unauthenticated tests miss business logic and authorisation flaws; 16.13 expects authenticated testing for critical applications. See the Web Application Security Testing Guide.
Root cause analysis that stops at the bug: fixing the instance without changing the framework, pattern or training lets the same CWE return. Track recurrence to prove 16.3 works.

Practitioner checklist

Confirm the target Implementation Group: none of Control 16 at IG1, 16.1 to 16.11 at IG2, all 14 Safeguards at IG3.
Flag in-house and critical applications in the software inventory so coverage can be counted.
Approve and date the secure development process and severity rating system with all required components; diarise annual review.
Publish security.txt and a disclosure policy, and track external reports with severity and timing fields.
Generate SBOMs per build, record component risk and support status, and review monthly.
Enforce secrets scanning with push protection and revoke any exposed credential.
Use separate workload identities and secrets for production and non-production.
Train all developers at least annually with role-specific content and keep records.
At IG3, run SAST and DAST on every in-house application, authenticated penetration tests on critical ones, and threat models for new designs.

CIS Control 16 Application Software Security Guide: Safeguards, Implementation Groups and Evidence