Application Software Security
Manage 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.
Why Is This Control Critical?
Attacks often take advantage of vulnerabilities found in web-based and other application software. Vulnerabilities can be caused by coding mistakes, logic errors, incomplete requirements, and failure to test for unusual or unexpected conditions. Sophisticated attackers can find and exploit such vulnerabilities. Application security includes techniques such as security requirements, secure design, secure coding, secure deployment, vulnerability scanning, and web application firewalls.
Related Policy Templates
Safeguards (14)
| ID | Title | Function | IG | Checklist Items | Evidence |
|---|---|---|---|---|---|
| 16.1 | Establish and Maintain a Secure Application Development Process | Protect |
IG2
IG3
|
12 | 9 |
| 16.2 | Establish and Maintain a Process to Accept and Address Software Vulnerabilities | Protect |
IG2
IG3
|
10 | 7 |
| 16.3 | Perform Root Cause Analysis on Security Vulnerabilities | Protect |
IG2
IG3
|
8 | 5 |
| 16.4 | Establish and Manage an Inventory of Third>Party Software Components | Protect |
IG2
IG3
|
9 | 7 |
| 16.5 | Use Up>to>Date and Trusted Third>Party Software Components | Protect |
IG2
IG3
|
10 | 7 |
| 16.6 | Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities | Protect |
IG2
IG3
|
8 | 5 |
| 16.7 | Use Standard Hardening Configuration Templates for Application Infrastructure | Protect |
IG2
IG3
|
8 | 5 |
| 16.8 | Separate Production and Non>Production Systems | Protect |
IG2
IG3
|
5 | 3 |
| 16.9 | Train Developers in Application Security Concepts and Secure Coding | Protect |
IG2
IG3
|
7 | 5 |
| 16.10 | Apply Secure Design Principles in Application Architectures | Protect |
IG2
IG3
|
5 | 3 |
| 16.11 | Leverage Vetted Modules or Services for Application Security Components | Protect |
IG2
IG3
|
11 | 7 |
| 16.12 | Implement Code>Level Security Checks | Protect |
IG3
|
5 | 3 |
| 16.13 | Conduct Application Penetration Testing | Protect |
IG3
|
12 | 9 |
| 16.14 | Conduct Threat Modeling | Protect |
IG3
|
7 | 5 |
Audit Verification Details
Establish and maintain a secure application development process. In the process, address such items as: secure application design standards, secure coding practices, developer training, vulnerability management, security of third-party code, and application security testing procedures. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Contracts with third parties include security requirements.
Contract excerpts showing security clauses
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Vulnerability scans cover all in-scope assets and run at the defined frequency.
Scan reports with scope and schedule evidence
Changes to protection controls follow the change management process.
Change tickets, approval records
Vulnerabilities are remediated within defined SLAs by severity.
Remediation tracking with SLA compliance metrics
Exceptions and risk acceptances are documented and approved.
Exception/waiver records with management sign-off
Security awareness training is completed by all required personnel within the defined timeframe.
Training completion reports and compliance rates
Training effectiveness is measured (e.g., phishing simulation results).
Phishing simulation reports, quiz scores, trend data
Third-party service providers are inventoried and risk-assessed.
Vendor inventory, risk assessment reports, security scorecards
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Technical | Vulnerability scan reports showing scope and findings | Per scan cycle |
| Record | Vulnerability remediation tracking with SLA compliance metrics | Monthly |
| Record | Training completion records and compliance rates | Tracked continuously, reported quarterly |
| Document | Training content and curriculum documentation | Reviewed annually |
| Record | Third-party risk assessment reports and scorecards | Annually per vendor |
| Document | Vendor contracts with security requirements | Per contract cycle |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Establish and maintain a process to accept and address reports of software vulnerabilities, including providing a means for external entities to report. The process is to include such items as: a vulnerability handling policy that identifies reporting process, responsible party for handling vulnerability reports, and a process for intake, assignment, remediation, and remediation testing. As part of the process, use a vulnerability tracking system that includes severity ratings, and metrics for measuring timing for identification, analysis, and remediation of vulnerabilities. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard. Third-party application developers need to consider this an externally-facing policy that helps to set expectations for outside stakeholders.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Contracts with third parties include security requirements.
Contract excerpts showing security clauses
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Vulnerability scans cover all in-scope assets and run at the defined frequency.
Scan reports with scope and schedule evidence
Changes to protection controls follow the change management process.
Change tickets, approval records
Vulnerabilities are remediated within defined SLAs by severity.
Remediation tracking with SLA compliance metrics
Exceptions and risk acceptances are documented and approved.
Exception/waiver records with management sign-off
Third-party service providers are inventoried and risk-assessed.
Vendor inventory, risk assessment reports, security scorecards
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Technical | Vulnerability scan reports showing scope and findings | Per scan cycle |
| Record | Vulnerability remediation tracking with SLA compliance metrics | Monthly |
| Record | Third-party risk assessment reports and scorecards | Annually per vendor |
| Document | Vendor contracts with security requirements | Per contract cycle |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Perform root cause analysis on security vulnerabilities. When reviewing vulnerabilities, root cause analysis is the task of evaluating underlying issues that create vulnerabilities in code, and allows development teams to move beyond just fixing individual vulnerabilities as they arise.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Vulnerability scans cover all in-scope assets and run at the defined frequency.
Scan reports with scope and schedule evidence
Changes to protection controls follow the change management process.
Change tickets, approval records
Vulnerabilities are remediated within defined SLAs by severity.
Remediation tracking with SLA compliance metrics
Exceptions and risk acceptances are documented and approved.
Exception/waiver records with management sign-off
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Technical | Vulnerability scan reports showing scope and findings | Per scan cycle |
| Record | Vulnerability remediation tracking with SLA compliance metrics | Monthly |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Establish and manage an updated inventory of third-party components used in development, often referred to as a “bill of materials,” as well as components slated for future use. This inventory is to include any risks that each third-party component could pose. Evaluate the list at least monthly to identify any changes or updates to these components, and validate that the component is still supported.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Contracts with third parties include security requirements.
Contract excerpts showing security clauses
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Inventory tool is deployed and all required data fields are populated.
Inventory tool screenshot, exported data with populated fields
Changes to protection controls follow the change management process.
Change tickets, approval records
Process exists to identify and remediate unauthorized or unmanaged items.
Exception reports, unauthorized asset remediation records
Third-party service providers are inventoried and risk-assessed.
Vendor inventory, risk assessment reports, security scorecards
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Technical | Asset/software inventory export with required fields populated | Exported quarterly for review |
| Record | Inventory review meeting minutes or sign-off | Per review cycle |
| Record | Third-party risk assessment reports and scorecards | Annually per vendor |
| Document | Vendor contracts with security requirements | Per contract cycle |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Use up-to-date and trusted third-party software components. When possible, choose established and proven frameworks and libraries that provide adequate security. Acquire these components from trusted sources or evaluate the software for vulnerabilities before use.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Contracts with third parties include security requirements.
Contract excerpts showing security clauses
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Vulnerability scans cover all in-scope assets and run at the defined frequency.
Scan reports with scope and schedule evidence
Changes to protection controls follow the change management process.
Change tickets, approval records
Vulnerabilities are remediated within defined SLAs by severity.
Remediation tracking with SLA compliance metrics
Exceptions and risk acceptances are documented and approved.
Exception/waiver records with management sign-off
Third-party service providers are inventoried and risk-assessed.
Vendor inventory, risk assessment reports, security scorecards
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Technical | Vulnerability scan reports showing scope and findings | Per scan cycle |
| Record | Vulnerability remediation tracking with SLA compliance metrics | Monthly |
| Record | Third-party risk assessment reports and scorecards | Annually per vendor |
| Document | Vendor contracts with security requirements | Per contract cycle |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Establish and maintain a severity rating system and process for application vulnerabilities that facilitates prioritizing the order in which discovered vulnerabilities are fixed. This process includes setting a minimum level of security acceptability for releasing code or applications. Severity ratings bring a systematic way of triaging vulnerabilities that improves risk management and helps ensure the most severe bugs are fixed first. Review and update the system and process annually.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Vulnerability scans cover all in-scope assets and run at the defined frequency.
Scan reports with scope and schedule evidence
Changes to protection controls follow the change management process.
Change tickets, approval records
Vulnerabilities are remediated within defined SLAs by severity.
Remediation tracking with SLA compliance metrics
Exceptions and risk acceptances are documented and approved.
Exception/waiver records with management sign-off
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Technical | Vulnerability scan reports showing scope and findings | Per scan cycle |
| Record | Vulnerability remediation tracking with SLA compliance metrics | Monthly |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Use standard, industry-recommended hardening configuration templates for application infrastructure components. This includes underlying servers, databases, and web servers, and applies to cloud containers, Platform as a Service (PaaS) components, and SaaS components. Do not allow in-house developed software to weaken configuration hardening.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Systems are configured per an approved hardening baseline (CIS Benchmarks, DISA STIGs).
Compliance scan results against the approved baseline
Only authorized software is permitted to execute, enforced via allowlisting.
Allowlist policy config, unauthorized software detection reports
Changes to protection controls follow the change management process.
Change tickets, approval records
Configuration drift is detected and remediated within defined timeframes.
Drift detection reports, remediation tickets
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Technical | Configuration compliance scan results against approved baseline | Scanned monthly |
| Document | Approved baseline configuration documentation | Reviewed quarterly |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Maintain separate environments for production and non-production systems.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Changes to protection controls follow the change management process.
Change tickets, approval records
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Ensure that all software development personnel receive training in writing secure code for their specific development environment and responsibilities. Training can include general security principles and application security standard practices. Conduct training at least annually and design in a way to promote security within the development team, and build a culture of security among the developers.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Changes to protection controls follow the change management process.
Change tickets, approval records
Security awareness training is completed by all required personnel within the defined timeframe.
Training completion reports and compliance rates
Training effectiveness is measured (e.g., phishing simulation results).
Phishing simulation reports, quiz scores, trend data
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Record | Training completion records and compliance rates | Tracked continuously, reported quarterly |
| Document | Training content and curriculum documentation | Reviewed annually |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Apply secure design principles in application architectures. Secure design principles include the concept of least privilege and enforcing mediation to validate every operation that the user makes, promoting the concept of "never trust user input." Examples include ensuring that explicit error checking is performed and documented for all input, including for size, data type, and acceptable ranges or formats. Secure design also means minimizing the application infrastructure attack surface, such as turning off unprotected ports and services, removing unnecessary programs and files, and renaming or removing default accounts.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Changes to protection controls follow the change management process.
Change tickets, approval records
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Leverage vetted modules or services for application security components, such as identity management, encryption, and auditing and logging. Using platform features in critical security functions will reduce developers’ workload and minimize the likelihood of design or implementation errors. Modern operating systems provide effective mechanisms for identification, authentication, and authorization and make those mechanisms available to applications. Use only standardized, currently accepted, and extensively reviewed encryption algorithms. Operating systems also provide mechanisms to create and maintain secure audit logs.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Encryption is applied to all in-scope data at rest and in transit using approved algorithms.
Encryption status reports, TLS scan results, disk encryption audit
Audit logging is enabled on all in-scope systems and forwarded to centralized SIEM.
SIEM source status dashboard, log forwarding configuration
Multi-factor authentication is enforced on all in-scope systems and accounts.
MFA enrollment status reports, conditional access policy config
Changes to protection controls follow the change management process.
Change tickets, approval records
Encryption keys are managed per the key management procedure (rotation, storage, access).
Key rotation logs, key management system audit
Logs are retained per the defined retention period and reviewed on schedule.
Retention policy config, log review records
MFA exceptions are documented, approved, and compensating controls are in place.
Exception records with compensating control documentation
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Technical | Encryption configuration evidence (disk encryption status, TLS settings) | Scanned monthly |
| Document | Key management procedures and key rotation records | Reviewed annually |
| Technical | SIEM dashboard showing log sources and collection status | Captured monthly |
| Record | Log review records and findings | Per review cycle |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Apply static and dynamic analysis tools within the application life cycle to verify that secure coding practices are being followed.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Changes to protection controls follow the change management process.
Change tickets, approval records
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Conduct application penetration testing. For critical applications, authenticated penetration testing is better suited to finding business logic vulnerabilities than code scanning and automated security testing. Penetration testing relies on the skill of the tester to manually manipulate an application as an authenticated and unauthenticated user.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Audit logging is enabled on all in-scope systems and forwarded to centralized SIEM.
SIEM source status dashboard, log forwarding configuration
Vulnerability scans cover all in-scope assets and run at the defined frequency.
Scan reports with scope and schedule evidence
Changes to protection controls follow the change management process.
Change tickets, approval records
Logs are retained per the defined retention period and reviewed on schedule.
Retention policy config, log review records
Vulnerabilities are remediated within defined SLAs by severity.
Remediation tracking with SLA compliance metrics
Exceptions and risk acceptances are documented and approved.
Exception/waiver records with management sign-off
Penetration testing is performed by qualified testers within the past 12 months.
Pentest report, tester qualifications, scope documentation
Pentest findings are remediated and validated through retesting.
Remediation tracking, retest validation report
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Technical | SIEM dashboard showing log sources and collection status | Captured monthly |
| Record | Log review records and findings | Per review cycle |
| Technical | Vulnerability scan reports showing scope and findings | Per scan cycle |
| Record | Vulnerability remediation tracking with SLA compliance metrics | Monthly |
| Record | Penetration test report and executive summary | Per engagement |
| Record | Remediation tracking and retest validation results | Post-engagement |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |
Conduct threat modeling. Threat modeling is the process of identifying and addressing application security design flaws within a design, before code is created. It is conducted through specially trained individuals who evaluate the application design and gauge security risks for each entry point and access level. The goal is to map out the application, architecture, and infrastructure in a structured way to understand its weaknesses.
Audit Verification Checklist
A governing policy or procedure exists, is approved by management, and was reviewed within the last 12 months.
Signed/approved policy document with review date
Roles and responsibilities for this safeguard are formally assigned and communicated.
RACI matrix, role assignment records, or job descriptions
Required protection controls are deployed and configured per the approved baseline.
Configuration exports, screenshots, or compliance scan results
Control effectiveness has been validated through testing.
Test results, validation reports, or scan output
Changes to protection controls follow the change management process.
Change tickets, approval records
Security awareness training is completed by all required personnel within the defined timeframe.
Training completion reports and compliance rates
Training effectiveness is measured (e.g., phishing simulation results).
Phishing simulation reports, quiz scores, trend data
| Type | Evidence Item | Frequency |
|---|---|---|
| Technical | Configuration screenshots or exports showing protection controls enabled | Captured quarterly |
| Document | Procedure documentation for protection measures | Reviewed annually |
| Record | Training completion records and compliance rates | Tracked continuously, reported quarterly |
| Document | Training content and curriculum documentation | Reviewed annually |
| Document | Governing policy document (current, approved, communicated) | Reviewed annually |