Let’s Start with SDLC
DevSecOps, fully spelled out as development, security, and operations, is a newer concept where security is integrated at every level of the development process. This includes the initial concept, integration, testing, and deployment of an application. However, before we dig into DevSecOps, we must first understand the process that came before and has recently evolved into it: the Software Development Life Cycle (SDLC).
The SDLC is a structured process that was developed in the days of Waterfall methodology. Waterfall set forth a linear path to achieve milestones through specific phases. Like Waterfall, the SDLC is made up of specific steps in the process of creating a software application and/or system. The steps include:
- Planning—The planning phase typically requires the collection of requirements from product owners/stakeholders, cost-benefit analysis, scheduling, resource estimation, and allocation. This step is where a requirements document is created, and a schedule is laid out for the project’s completion. The goal is to establish a comprehensive understanding of what the software needs to achieve. The common deliverables from this phase include:
- Approval and Sign-off
- Change Control Process
- Dependencies and Constraints
- Feasibility Study
- Initial Risk Assessment
- Milestone Schedule
- Project Charter
- Project Kickoff Meeting
- Project Plan (includes Project Schedule, Resource Allocation, Budget, Risk Management Plan, Communication Plan)
- Project Scope Statement
- Project Team Roles and Responsibilities
- Quality Assurance Plan
2. Analysis—This step is where the requirements gathered from meetings with stakeholders are analyzed to see if they are valid and how to integrate the requirements into the system. The common deliverables from this phase include:
- Business Requirements (business goals, objectives, constraints, any regulatory or compliance requirements)
- Constraints and Assumptions (budget, schedule, assumptions from the requirements gathering process)
- Data Flow Diagrams (data sources, processes, data stores, data destinations, visualize how information is processed)
- Functional Specifications (input/output details, business rules, algorithms/calculations the system must perform)
- Requirements Document (Requirements (Functional and Non-Functional), User Stories or Use Cases, Data Requirements)
- Stakeholder Sign-off (gathered requirements represent the needs and expectations)
- Traceability Matrix (track and trace requirements through the project to ensure each requirement is addressed and tested in development)
- Use Case Diagrams (graphical representation of how different users or system components interact with the system)
- User Interface Requirements (how the UI should look and behave, layout, navigation, user interactions)
3. Design—Developers and engineers determine the best solution based on the requirements gathered. Tool selection, how to integrate the application within existing infrastructure and technology choices will all be considered at this step. The initial architecture will also be created based on the requirements provided. The common deliverables from this phase include:
- Data Flow Diagrams
- Database Design
- Detailed Design Specifications
- Documentation Standards
- Hardware and Software Requirements
- Performance and Scalability Considerations
- Security Design
- System Architecture
- System Interfaces
- Technical Specifications
- Testing and Quality Assurance Plan
- User Interface Design
4. Implementation—Coding is broken into modules based on design documents created in the Design phase. Implementation will often be the most prolonged phase, as this is where most of the coding takes place. The common deliverables from this phase include:
- Bug and Issue Reports
- Build and Deployment Scripts
- Change Logs
- Code Review Documentation and Approval
- Deployment Plan
- Deployment Documentation
- Developer Documentation
- Documentation Updates
- Executable Code
- Integration Code
- Integration Test Cases
- Peer Review Reports
- Progress Reports
- Status Meetings
- System Documentation (Code Comments, Code Documentation)
- Test Data
- Test Environment Setup
- Test Plans
- Test Results
- Unit Test Cases
- Version Control Updates
5. Testing and Integration—Once the code is developed, it will go through functional testing (unit testing, integration testing, system testing, and acceptance testing) and non-functional testing (maintenance testing and documentation testing). The tests will determine if the developed application meets the requirements stated by the stakeholders. The common deliverables from this phase include:
- Approval for Deployment
- Defect Reports
- Documentation Updates
- Integration Test Results
- Regression Test Suite
- Release Readiness Assessment
- System Test Results
- Test Cases
- Test Completion Report
- Test Data
- Test Environment Setup
- Test Plan
- Test Scripts and Automation
- Test Summary Report
- Traceability Matrix
- User Plan
- UAT Test Results
6. Deployment—The deployment phase falls within testing and integration as the early deployed version will often be hands-on for the customer to use. When the bugs and any requests/changes are fixed, a file production-ready application version will be deployed. The common deliverables from this phase include:
- Backup and Recovery Plans
- Change Management Records
- Configuration Files
- Data Migration Plan
- Deployed Software
- Deployment Checklist
- Deployment Plan
- Deployment Scripts
- Deployment Sign-off
- Feedback Collection Mechanism
- Handover Documentation
- Monitoring and Maintenance Plans
- Post-Deployment Review
- Post-Deployment Support Plan
- Production Environment Documentation
- Release Notes
- Security and Access Controls
- System Documentation
- User Documentation
7. Maintenance—This phase involves fixing bugs, resolving customer issues, managing software changes, and monitoring system performance, security, and user experience to identify new ways to improve the existing software. The common deliverables from this phase include:
- Backup and Recovery Plans
- Bug Reports and Issue Tracking
- Capacity Planning
- Change Management
- Change Requests
- Compliance and Regulatory Updates
- Data Backup and Recovery
- Defect Resolution
- Documentation Updates
- End-of-Life (EOL) Planning
- Feedback and User Satisfaction Reports
- Incident Reports
- Knowledge Base
- License Management
- Patch Releases
- Performance Monitoring
- Performance Optimization
- Post-Implementation Reviews
- Security Updates
- Service Level Agreements (SLAs)
- System Logs and Audits
- Testing Documentation
- User Support and Helpdesk Services
- User Training
- Version Control and Configuration Management
As with Waterfall, the early SDLC was limited and had to be followed precisely to produce a lower-cost, effective product. With applications becoming more advanced, produced at higher rates, developed in Agile systems, and only some requirements being available upfront, the SDLC can only struggle with significant modifications. Some of the common issues with the SDLC are as follows:
- Assumes that the requirements of a system can be frozen
- Costly and requires more time, in addition to the detailed plan
- Customer Feedback Delay
- Difficulty in Handling Complex Projects
- Documentation Overload
- Flexibility and adjusting the scope is difficult and expensive
- High Risk of Scope Creep
- High Upfront Costs
- Ineffective Risk Management
- Inefficient Resource Utilization
- Lack of Stakeholder Involvement
- Limited Flexibility
- Limited Transparency
- Long Project Timelines
- Progress of the stage is hard to measure while it is still in development
- Very difficult to go back to any stage after it is finished
Since working with the Waterfall Methodology, the SDLC has adjusted to modern times and processes. One of the latest evolutions is into the DevSecOps flow.
It’s Like SDLC but Not
DevSecOps could be considered an evolution of the SDLC. The significant improvement in DevSecOps is the approach of including security from the beginning, also known as the “shift left” approach. Traditionally, security is added at the end of the lifecycle by a security team not involved during the development process. Once security is tacked on at the end, a separate Quality Assurance (QA) team will come in to confirm that everything passes testing to meet standards. This may have worked in a Waterfall environment, but now teams are much more flexible; they create applications in weeks or days using an Agile methodology. Adding security at the end of an Agile process would not make sense and create delays for the project.
The DevSecOps process integrates security development throughout the entire process. This allows for quicker and cheaper security fixes before they reach production. The security will also work closely with the development and operation teams, no longer setting security into a lone silo. Having security work together with operations and development will assist in automating software delivery down the line.
While a simple change of including security from the start does not seem like a big difference, it results in the following benefits for application development:
- Automation—DevSecOps is compatible with the continuous integration/continuous delivery (CI/CD) pipeline, where security is tested automatically in the pipeline, and appropriate patches are applied when needed.
- Collaboration—Foster a culture of collaboration among development, security, and operations teams. Encourage open communication and shared responsibility for security.
- Continuous Security Testing—DevSecOps promotes the continuous testing of applications for security vulnerabilities (i.e., SAST, DAST, Container Security, etc.).
- Compliance as Code—Compliance requirements are automated and integrated into the development and deployment process, ensuring the applications meet regulatory and security standards.
- Fast and Cost-Effective Software Delivery—Integrating security from the start minimizes the need to repeat steps to address security concerns, which increases the speed at which the team can develop a secure product.
- Incident Response Planning—DevSecOps includes developing incident response plans and playbooks to address security incidents and breaches quickly and effectively; conduct tabletop exercises to test and improve incident response procedures.
- Infrastructure as Code (IaC) Security—Apply security practices to infrastructure automation scripts and templates, such as those used in cloud provisioning (i.e., AWS CloudFormation, Terraform, etc.).
- Improved and Proactive Security—Within DevSecOps, code is reviewed, audited, scanned, and tested for security issues (IBM, 2023). Any issues discovered are remediated quicker due to the development, operations, and security teams collaborating throughout the project.
- Process is Adaptable—DevSecOps adapts to the maturation of a company’s security posture. A mature process will include automation, configuration management, orchestration, containers, immutable infrastructure, and serverless compute environments (IBM, 2023).
- Rapid Security Patching—DevSecOps integrates vulnerability scanning and patching into the release cycles. This leads to less time for an application to be vulnerable to threats.
- Real-Time Monitoring and Alerting—DevSecOps teams use real-time monitoring and alerting to detect and respond to incidents as they occur.
- Security Metrics and Reporting—DevSecOps teams establish key performance indicators and metrics to measure the effectiveness of security practices and report on security posture.
- Training and Education—Security awareness and training are key components of the DevSecOps culture. Developers and operations personnel are educated about security best practices with respect to security in their roles.
DevSecOps Best Practices
Like any process, it is only successful if best practices are followed:
- Access Control—Implement the principle of least privilege for user and system access. Enforce strong authentication and authorization controls.
- API Security—Secure APIs and enforce strong authentication, authorization, and encryption for all API endpoints; reference the OWASP Top 10 API Security Risks.
- Automation—Per previous.
- Collaborative Culture—Per previous.
- Compliance as Code—Per previous.
- Container Security—Secure containerized applications by employing best practices for image scanning, container isolation, and runtime protection.
- Continuous Feedback—Encourage feedback from security, development, and operations teams to identify and address security issues and improvement opportunities.
- Continuous Improvement—Continuously review and improve security practices and processes to address new threats and vulnerabilities.
- Continuous Monitoring—Per previous.
- Continuous Security Testing—Per previous.
- Documentation and Knowledge Sharing—Document security practices, policies, and procedures; share knowledge and best practices across teams.
- Education—Everyone involved with the delivery process should be familiar with the basic principles of application security, the Open Web Application Security Project (OWASP) Top 10, application security testing, and other security engineering practices. Developers need to understand threat models compliance checks, know how to measure risks and exposure, and implement security controls.
- Immutable Infrastructure—Strive for immutable infrastructure, where infrastructure components are treated as disposable, and changes are made by replacing entire components rather than modifying them.
- Incident Response—Per previous.
- Infrastructure as Code (IaC) Security—Per previous.
- Leadership—A process cannot be effective with poor leadership. Security and product ownership need to be communicated early on and follow a workflow that meets the needs of each group involved. This will make the development teams more engaged in the project.
- Multi-Factor Authentication (MFA)—Implement MFA for user authentication, especially for critical systems and administrative access.
- Patch Management—Regularly apply security patches and updates to software, libraries, and infrastructure components.
- Real-Time Monitoring and Alerting—Per previous.
- Secure Code Reviews—Conduct regular code reviews focusing on security. Use code review tools to identify vulnerabilities and potential issues.
- Secure Design—Perform threat modeling and security architecture reviews during the design phase to identify and address potential security risks.
- Secure Development Tools—Choose and use secure development tools, libraries, and frameworks that have undergone security assessments and have a track record of addressing vulnerabilities promptly.
- Security as Code—Write security policies, configurations, and rules as code; this enables version, test, and manage security as part of the codebase.
- Security Champions—Appoint security champions within development and operations teams to drive security awareness and best practices.
- Security Metrics and Reporting—See previous.
- Shift Left—We mentioned this earlier meaning that security considerations are integrated as early as possible (includes secure coding practices, threat modeling, and security reviews to the beginning of the SDLC. Using security from the start will ensure vulnerabilities are discovered and mitigated before becoming a pricey and time-consuming proposition.
- Third-Party Risk Management—Assess and monitor the security of third-party components and services used in your applications; ensure that they meet your security standards (i.e., Software Bill of Materials).
- Threat Intelligence—Stay informed about emerging threats and vulnerabilities by leveraging threat intelligence sources; use threat information to proactively adjust security measures.
- Traceability—A team can track configuration items across the development cycle to where requirements are implemented in the code. This plays a crucial part in your organization’s control framework as it helps achieve compliance, reduce bugs, ensure secure code in application development, and help code maintainability.
- Training and Education—See previous.
- Zero-Trust Architecture—Embrace a zero-trust architecture, where trust is never assumed, and continuous verification is required to access resources. Implement strong access controls and least privilege access principles.
We Have Established DevSecOps, Now What?
Now that DevSecOps is used for your software development, it is time to supercharge the process with the CI/CD pipeline. The CI/CD pipeline is a method that introduces automation into the application development process through a custom or third-party solution. The application going through the pipeline is continuously monitored and tested automatically. New code changes are regularly built, tested, and merged to a shared repository (e.g., GitHub) for developers. The idea is to have a straightforward path for development instead of multiple development branches that could conflict with each other at different phases.
When a developer changes the code in the application, the application is then automatically bug-tested and uploaded to a repository. The operations team can pull the updated application from the repository and push it into a live environment. If, at any step in the pipeline, the application does not meet the required settings at that phase, the process stops until fixes are completed.
DevSecOps combined with a CI/CD pipeline setup allows the development, operations, and security teams to work more effectively and efficiently. Manual development work that would usually be siloed out is now done together with automation included. This gives teams more time to focus on solutions instead of rewriting code to accommodate dependencies. The automation factor also removes the human aspect from the development process in the sense of fewer opportunities for human input error. CI/CD automation is a repeatable process as well as predictable. Further, teams can receive feedback sooner and implement the changes quicker with these processes in place.
DevSecOps is Here to Stay
Although the concept of DevSecOps has been floating around for a while now, some organizations still need to implement it. They need help in their ways of siloed teams, manual corrections of application code, and single milestones with no flexibility. DevSecOps frees teams from this rudimentary thinking and allows them to create more secure applications quickly and reliably. Any changes in requirements are easily managed as DevSecOps allows for flexibility by facing issues on the spot and remediating them. Add CI/CD pipeline methods to DevSecOps, and you will eventually have an automated setup that delivers applications that predictably meet security and end-user requirements. DevSecOps is a methodology that will remain and adapt to the software development process while providing a better team collaboration environment.
Sources:
https://aws.amazon.com/what-is/sdlc/
https://medium.com/@jilvanpinheiro/software-development-life-cycle-sdlc-phases-40d46afbe384
https://www.linkedin.com/pulse/evolution-system-development-life-cycle-sdlc-shantanu-choudhary/
https://w-c-s-desilva.medium.com/sdlc-methods-and-their-advantages-and-disadvantages-fa398ec62e69
https://www.ibm.com/topics/devsecops
https://www.redhat.com/en/topics/devops#continuous-deployment