This policy establishes the requirements for developing secure software applications and systems at [Company Name]. Its purpose is to integrate security throughout the entire Software Development Lifecycle (SDLC), minimize security vulnerabilities in custom-developed, bespoke, and commercial software, protect sensitive data processed or stored by applications (including but not limited to Cardholder Data - CHD), ensure compliance with regulatory requirements (including PCI DSS 4.0.1 Requirement Requirement 6), and reduce the overall risk profile of the organization.
Scope
This policy applies to all software development activities conducted by or for [Company Name], including the development of internal applications, bespoke software, customized commercial-off-the-shelf (COTS) software, mobile applications, web applications, APIs, microservices, and system scripts. It covers all phases of the SDLC, from requirements gathering and design through coding, testing, deployment, and maintenance. All employees, contractors, consultants, and third-party developers involved in these activities are subject to this policy. Special attention must be paid to applications that are part of, or could impact the security of, the Cardholder Data Environment (CDE).
Roles and Responsibilities
Role/Group
Key Responsibilities
Executive Management
Provide strategic direction and resources for secure development practices; Foster a security-aware development culture.
CISO / Head of Engineering
Own and approve this policy; Oversee the implementation and effectiveness of the secure SDLC; Ensure compliance and manage associated risks.
Information Security Team
Develop and maintain secure coding standards and guidelines; Provide security training requirements; Operate security testing tools (SAST, DAST, SCA); Perform security architecture reviews and code reviews; Manage application vulnerability findings.
Application Development Management
Ensure development teams adhere to this policy; Integrate security activities into project plans and SDLC processes; Allocate resources for security tasks; Track remediation of security findings.
Developers / Engineers
Adhere to secure coding standards; Participate in mandatory security training; Write secure code; Remediate identified vulnerabilities in their code; Utilize approved libraries/components; Participate in code reviews.
Integrate security testing (manual and automated) into the testing phase; Validate functionality of security controls; Verify remediation of security defects.
DevOps / Release Management
Implement secure build and deployment pipelines (CI/CD security); Ensure secure configuration of deployment environments; Manage application secrets securely.
Compliance / Audit Team
Independently verify adherence to this policy and associated procedures; Review training records, code review evidence, test results, and vulnerability remediation tracking.
Policy Requirements
1. Secure SDLC Integration
Security activities must be integrated into all phases of the Software Development Lifecycle (SDLC), from initial requirements gathering and design through development, testing, deployment, and ongoing maintenance.
Security requirements, including data protection, access control, and relevant compliance needs (e.g., PCI DSS), must be identified and documented during the requirements phase.
Threat modeling shall be performed during the design phase for critical applications or those handling sensitive data to identify potential threats and design appropriate controls.
2. Secure Coding Training (PCI DSS Req 6.2.1)
All developers, engineers, and architects involved in the software development lifecycle must receive formal training on secure coding practices upon hiring and at least annually thereafter.
Training must cover common vulnerabilities (e.g., OWASP Top 10), language-specific security issues, secure design principles, company-specific secure coding standards, and relevant compliance requirements (e.g., secure handling of CHD per PCI DSS).
Training completion must be tracked and documented.
3. Secure Coding Standards (PCI DSS Req 6.2.2)
Develop, document, and maintain secure coding standards based on industry best practices (e.g., OWASP Secure Coding Practices, CERT Secure Coding Standards) and relevant compliance requirements.
Standards must address key security areas, including but not limited to:
Input Validation: Validate all input (user-supplied, API calls, file uploads) for type, length, format, and range. Implement strong controls against injection flaws (SQLi, XSS, Command Injection, etc.).
Output Encoding: Properly encode output data displayed in user interfaces or passed to interpreters to prevent injection attacks (e.g., XSS).
Authentication and Session Management: Implement secure mechanisms for user authentication (strong password requirements, MFA where applicable), session management (secure session IDs, timeouts, proper logout).
Access Control: Enforce authorization checks based on the principle of least privilege for all application functions and data access requests.
Cryptography: Use approved, strong cryptographic algorithms and secure key management practices for protecting sensitive data (at rest and in transit), as defined in the Data Protection & Encryption Policy. Do not implement custom cryptography.
Error Handling and Logging: Implement robust error handling that does not reveal sensitive system information. Log security-relevant events (e.g., logins, failures, access violations, administrative actions) securely.
Data Protection: Minimize collection and storage of sensitive data. Protect sensitive data according to classification (e.g., never store SAD post-authorization, render stored PAN unreadable per PCI DSS Req 3). Avoid embedding sensitive data (e.g., credentials, keys) directly in code; use secure secret management solutions.
Implement a multi-faceted approach to security testing throughout the SDLC:
Code Reviews: Conduct code reviews for security vulnerabilities before code is moved into production. This can include manual peer reviews focused on security, and/or automated static analysis (SAST). Reviews must cover all custom code and be performed by knowledgeable personnel/tools. Review findings must be tracked and remediated.
Static Application Security Testing (SAST): Integrate automated SAST tools into the development workflow (e.g., in IDEs, CI/CD pipelines) to identify potential vulnerabilities early in the coding process.
Dynamic Application Security Testing (DAST): Perform automated DAST scans against running applications in test environments to identify runtime vulnerabilities (e.g., XSS, SQLi, insecure configuration).
Vulnerability Assessments: Conduct regular vulnerability assessments of applications and their environments to identify security weaknesses and prioritize remediation based on risk.
Manual Security Testing / Penetration Testing: Conduct manual security testing or penetration testing for critical applications or significant releases, focusing on business logic flaws, complex vulnerabilities, and overall security posture (per Vulnerability Management Policy).
Vulnerability Remediation: All identified security vulnerabilities must be risk-ranked (based on severity, exploitability, impact), tracked, and remediated according to timelines defined in the Vulnerability Management Policy. Remediation must be verified before closure.
Inventory: Maintain an accurate inventory of all third-party software components and libraries (including open-source software - OSS) used within custom and bespoke applications. This is often achieved using Software Composition Analysis (SCA) tools.
Vulnerability Monitoring: Implement processes and tools (e.g., SCA) to monitor third-party components for known vulnerabilities throughout their lifecycle.
Patching/Updating: Update or patch third-party components promptly when security vulnerabilities are identified, following the Vulnerability Management Policy timelines. If patches are unavailable, implement compensating controls or seek alternative components.
License Compliance: Ensure compliance with licensing requirements for all third-party components.
6. Secure Deployment and Configuration Management
All application deployments to production must follow the [Company Name] Change Management Policy.
Utilize secure configuration management practices for application environments (servers, containers, PaaS configurations), adhering to the System & Configuration Management Policy. Use Infrastructure as Code (IaC) with security checks where possible.
Implement secure practices for managing application secrets (API keys, database credentials, certificates) using approved tools (e.g., secure vaults) – never store secrets directly in code or version control.
7. Protection of Sensitive Data within Applications
Ensure Sensitive Authentication Data (SAD) is never stored after authorization.
Ensure stored PAN is rendered unreadable (encrypted, hashed, tokenized, or truncated) per policy. PAN must be masked when displayed (max first 6/last 4).
Minimize the application's access to sensitive data based on least privilege.
Ensure secure logging practices that do not log sensitive data unless explicitly required, masked, and secured.
8. Inventory of Bespoke and Custom Software (PCI DSS Req 6.3.1)
Maintain an accurate and up-to-date inventory of all bespoke and custom software developed internally or by third parties for [Company Name].
The inventory should include application name, version, owner, criticality, location, technologies used, and development status. This inventory supports vulnerability management and compliance tracking.
9. Public-Facing Web Application Security (PCI DSS Req 6.4.1)
For public-facing web applications, implement one of the following measures to continually detect and prevent web-based attacks:
Deploy an automated technical solution such as a Web Application Firewall (WAF) in front of the application, configured to block common attacks and updated regularly.
OR, conduct vulnerability assessments/reviews of the application at least every six months by qualified personnel/tools, ensuring vulnerabilities are addressed.
Both methods require regular review and updates to ensure effectiveness against current threats.
Enforcement
Non-compliance with this Secure Development Policy may result in applications being denied deployment to production, require immediate remediation efforts, and may lead to disciplinary action, up to and including termination of employment or contract, in accordance with established HR policies.
Code containing critical vulnerabilities identified post-deployment may require emergency patches or application rollback.
Exceptions to this policy require a documented technical or business justification, formal risk assessment identifying potential impacts and compensating controls, and written approval from the CISO / Head of Engineering and potentially Executive Management based on risk. Approved exceptions must be time-bound and reviewed regularly.
Revision History
Version
Date
Author
Change Details
1.0
[Date]
[Author Name]
Initial policy release
[Ver #]
[Date]
[Author Name]
[Summary of changes]
Approval
Name
Title
Signature
Date
[Exec Name]
[Executive Title, e.g., CTO]
[Date]
[CISO Name]
[CISO / Head of Engineering]
[Date]
Appendix A: Secure SDLC Phases and Key Security Activities
graph LR
A[1. Requirements] --> B(2. Design)
B --> C(3. Implementation or Coding)
C --> D(4. Testing)
D --> E(5. Deployment)
E --> F(6. Maintenance)
subgraph Requirements_Phase
A1[Identify Security Requirements]
A2[Identify Data Sensitivity]
A --> A1 --> A2
end
subgraph Design_Phase
B1[Threat Modeling]
B2[Secure Design Review]
B3[Define Security Controls]
B --> B1 --> B2 --> B3
end
subgraph Implementation_Phase
C1[Follow Secure Coding Standards]
C2["Use Approved Libraries (SCA)"]
C3[Peer Code Reviews - Security Focus]
C --> C1 --> C2 --> C3
end
subgraph Testing_Phase
D1["Static Analysis (SAST)"]
D2["Dynamic Analysis (DAST)"]
D3[Manual Security Testing / Pen Test]
D4[Remediate Findings]
D --> D1 --> D2 --> D3 --> D4
end
subgraph Deployment_Phase
E1[Secure Configuration Review]
E2[Change Management Approval]
E3[Secure Deployment Pipeline]
E --> E1 --> E2 --> E3
end
subgraph Maintenance_Phase
F1[Ongoing Vulnerability Scanning]
F2["Patching and Updates (Incl. Libraries)"]
F3[Incident Response]
F4[Secure Decommissioning]
F --> F1 --> F2 --> F3 --> F4
end
style F fill:#eee,stroke:#333,stroke-width:1px
(This is not exhaustive; detailed language/framework-specific checklists should be used)
Input Validation: Is all external input (user fields, API parameters, file uploads, URL parameters, headers) validated for type, length, format, and range on the server-side? Are allow-lists used where possible?
Output Encoding: Is all dynamic output displayed to users properly encoded based on context (HTML, JavaScript, URL) to prevent XSS?
Authentication: Is authentication strong? Is MFA used where required? Are credentials stored securely (hashed/salted)? Are brute-force protections in place?
Session Management: Are session IDs generated securely (long, random)? Are they transmitted securely (HTTPS only, secure flags)? Are session timeouts enforced (server-side)? Is logout functionality secure?
Access Control: Are authorization checks performed for every sensitive function/data access request? Is access based on user roles/permissions (least privilege)? Are checks performed server-side?
Cryptography: Are standard, approved cryptographic libraries used? Are keys managed securely (not hardcoded)? Is sensitive data encrypted at rest/in transit per policy?
Error Handling: Do error messages avoid revealing sensitive system information or debugging details? Are errors logged securely?
Logging: Are security-relevant events (logins, failures, critical actions) logged with sufficient detail (who, what, when, where, outcome)? Are logs protected from tampering?
Data Protection: Is SAD never stored? Is PAN protected (masked, encrypted, truncated, hashed)? Is sensitive data exposure minimized in logs and UI?
Dependency Management: Are third-party libraries from trusted sources? Are known vulnerabilities in dependencies being tracked and addressed?
Secure Defaults: Does the application default to secure settings?
Appendix C: Security Testing Types and Frequency - Example
Testing Type
Frequency / Trigger
Responsibility
Tools / Method Example
Secure Code Training
Annually & Onboarding
HR / InfoSec / Dev Mgmt
Training Platform / Workshop
Threat Modeling
Design Phase (New Apps / Major Features)
Architect / Dev Team / InfoSec
STRIDE / PASTA / Whiteboard
Secure Code Review (Peer)
During Code Development (e.g., Pull Requests)
Development Team
Manual Review Checklist
Static Analysis (SAST)
Integrated into CI/CD Pipeline / Pre-Commit Hooks
Dev Team / InfoSec
SonarQube, Checkmarx, Veracode
Software Composition Analysis (SCA)
Integrated into CI/CD Pipeline / Regular Scans
Dev Team / InfoSec
OWASP Dep Check, Snyk, Dependabot
Dynamic Analysis (DAST)
During Testing Phase / Regularly in Test Environment
QA / InfoSec
OWASP ZAP, Burp Suite Pro
Manual Security Testing / Pen Test
Annually / After Significant Changes (Critical Apps)
InfoSec / Third Party
Manual Testing / Burp Suite
Public Web App Vulnerability Review / WAF Review
Continuously (WAF) / Every 6 Months (Review - if no WAF)
Test changes before deployment; Documented approval required.
Your perspective on this PCI DSS requirement matters! Share your implementation experiences, challenges, or questions below.
Your insights help other organizations improve their compliance journey and build a stronger security community.Comment Policy
