CIS Control 16 covers the security life cycle of in-house developed, hosted or acquired software: secure development process, vulnerability handling, third-party components, hardening, environment separation, developer training, code checks, application penetration testing and threat modeling.
The documented secure development process covering design standards, coding practices, developer training, vulnerability management, third-party code and security testing; the governing safeguard for Control 16.
A process to accept and address software vulnerability reports, including an external reporting channel, a handling policy, intake to remediation testing and a tracking system with severity ratings and timing metrics.
Performing root cause analysis on security vulnerabilities so development teams fix the underlying issues in code instead of only individual findings.
Keeping an inventory, often called a bill of materials, of third-party components used or planned in development, with each component's risks and a monthly review.
Using current, trusted third-party components from trusted sources, or evaluating them for vulnerabilities before use; the selection counterpart to the inventory in 16.4.
A severity rating system and process for application vulnerabilities that sets fix order and a minimum security bar for releasing code, reviewed annually.
Applying standard, industry-recommended hardening templates to application infrastructure such as servers, databases, web servers, containers, PaaS and SaaS, without letting in-house software weaken them.
Maintaining separate environments for production and non-production systems, and the evidence that shows the separation holds.
Training all software development personnel in secure coding for their environment and responsibilities at least annually; the developer-specific counterpart to role-based training in 14.9.
Applying secure design principles in application architectures, such as least privilege, validating every operation and input, and minimizing the attack surface.
Relying on vetted modules or platform services for security functions such as identity, encryption and audit logging, and only on standardized, extensively reviewed encryption algorithms.
Running static and dynamic analysis tools in the application life cycle to verify secure coding practices are followed; an IG3 safeguard.
Penetration testing applications, including authenticated testing of critical applications to find business logic flaws that scanners miss; the application-level counterpart to Control 18.
Threat modeling applications before code is written, by trained individuals who evaluate risks for each entry point and access level; an IG3 safeguard.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.