The Secure Software Development Lifecycle (SSDLC) process discussed earlier is built around a custom security policy, security standards, and security best practices, and completed through extensive security training and education. While the security policy is an important factor, security standards, best practices, and education are crucial to make an SSDLC program successful.

The security standards and security best practices include security relevant government standards and regulations (eg. NIST, HIPAA, PII regulations, …), but also established industry best practices (e.g. OWASP best practices for web application development, PCI-DSS compliance requirements for credit card pyaments, etc). Some standards and best practices are fairly universal, while others may only be relevant for specific projects. As an example, a web application that is processing credit card information will have to follow PCI-DSS regulations, be compliant with the relevant privacy standards, and implement a good deal of the OWASP recommended best practices. An application for a smartphone without its own billing system and without any credit card payment processing on the other hand can skip the PCI specific requirements.

An ongoing activity in the SSDLC is continuous security training and security education. This is fundamental for implementing a successful SSDLC program. Training and education must include all project members: developers, QA, architects, legal, project management, etc. Everyone needs to get a tailored training to understand both how the SSDLC works, and about foundational concepts like secure design, threat modeling, secure coding, and security testing. Depending on the project, the training can include aspects on relevant standards and best practices.

Security training can come in many forms, such as instructor led trainings, recorded video trainings, books, and training on the job. Once everyone in the team has reached a minimum baseline, I found training on the job to be the most effective and efficient in particular for the technical staff. When someone in the team (good case) or in the public (customers, white hats, black hats – bad case) has found a security vulnerability, I recommend to get at least the entire technical team (architect, dev, QA, operations) together for a post-mortem analysis. The person who found the issue then explains the problem, and asks the team to create a fix and a regression test to prevent the problem from happening again in the future. Also, the team must come up with a mitigation that can be used by operations to protect deployments when the latest update with the security fix cannot yet be installed.