Embedding security – Security Compliance with AWS Config, AWS Security Hub, and Automated Remediation
Embedding security
While security needs to be embedded within the different SDLC stages, it also needs to evolve as software development practices move toward agile methods. Let’s explore how the continuous and rapid delivery models of agile influence the security landscape.
Security in the traditional SDLC
Traditionally, security in the SDLC was a sequential process, aligning with the structured phases of the development model. This approach entails separate, distinct security activities at each stage of the SDLC, constituting what is commonly referred to as the Secure SDLC (SSDLC) model. The following security activities are commonly included in the SSDLC flow:
- Planning stage: Security resource allocation is a key activity, setting the groundwork for subsequent phases
- Analysis stage: Involves data classification based on Confidentiality, Integrity, and Availability (CIA) requirements, risk profile analysis, and security requirements gathering
- Design stage: Focuses on threat modeling and risk assessment to preemptively identify potential security issues
- Development stage: Includes activities such as source code review (static testing) and scanning for vulnerabilities in libraries and dependencies
- Testing stage: Entails vulnerability assessment and dynamic testing, such as penetration testing, to identify and mitigate security risks
- Deployment and maintenance stage: Focuses on fixing vulnerabilities, ongoing security monitoring, and addressing residual risks
While this method provided a comprehensive security framework, it was often rigid and slow to adapt to changes, posing challenges in dynamic development environments.
Shifting security to the left
In agile software development, aligning security with rapid development cycles presents a significant challenge. Traditionally, the SSDLC relied on specialized security teams, leading to extended timelines and potential friction with development teams focused on speed and cost-effectiveness. This conflict is pronounced in agile methodologies where intensive security processes can hinder the swift progression of development sprints.
To resolve this, a shift-left approach in security is gaining traction. The term derives from the usual graphical representation of a process in the form of stages arranged in chronological order from left to right. As can be seen in Figure 12.2, it involves integrating security early in the development cycle, particularly during the design phase. This strategy enables developers to incorporate secure coding practices from the outset and utilize automated tools for code auditing, enhancing the overall security quality. Shifting security left aligns with the agile model’s smaller, iterative changes, reducing the need for extensive security checks at every update. While not eliminating the need for rigorous security assessments, this approach allows for their strategic scheduling, decoupling them from the development cycle’s pace:
Figure 12.2 – Shift-left security principle
By adopting this shift-left approach, organizations can maintain high security standards while embracing the agility and speed of modern software development. It offers a balanced solution where security is a continuous, integrated element of the development process, tailored to an organization’s risk tolerance and maturity level.