Evolving from DevOps to DevSecOps, is it a ‘pipeline dream’ or something that can work within an organisation. This article covers the areas a business need to focus on to help make it happen.
DevOps practices (combination of development and IT operations) can be critical to a business and its profitability, so it is important to remember the value. How software is written from design through to release is referred to as the software development lifecycle. It is this lifecycle and each stage in development, security professionals are concerned with the introduction of security risks. How do we introduce security with the aim to reduce the chance of compromise while maintaining profitability, agility and competitive edge?
Company culture, the business itself will have to see the need for and promote security. The security team alone will not create change, building collaboration and communication between development, operations, and security teams is essential. For collaboration to happen consistently, trust needs to be gained, continued small initiatives where teams work together to complete small work items quickly for the benefit of all is the most effective way to build trust and rapport. Development teams will not be won over with PowerPoint, nice looking tools and talk. A common collaboration effort is using security champions, people who work in DevOps and promote security. Each organisation is different in their approach, what is clear, for successful relationships to succeed, work needs to be completed fast, often and as a team at all times.
Designs, Security Requirements & Threat Modelling. Designs give the widest audience possible a clear understanding of what a solution will do. The more communication required to explain something, the greater the chance of misunderstanding, distraction and loss of critical information. Requirements are the high-level statements of what is needed, in this case security related, such as Authentication, encryption and so on and do not go into too much detail how this is done. Threat modelling is a thought process requiring as many of the development team as possible to review the design and requirements to think of all scenarios that could affect a solution and pre-empt with appropriate security controls. Having all three vastly improves the security in a solution as early as possible and demonstrates the importance of security early.
Secure coding should be implemented, including code reviews to identify vulnerabilities, this can be achieved using tools for static code analysis. These tools help identify common errors made by developers that if go unresolved could lead to a vulnerability. Security standards and guidelines such as OWASP give developers best practices when coding. Guidelines cover areas such as input validation, handling of personal and sensitive data, authentication, and API security. Security tools can also be built into and integrated as automated testing into the CI (continuous integration) pipeline. The tools used in an automated way include dynamic application security testing (DAST) tools and vulnerability scanners to check the runtime running version of the code.
Continuous Monitoring and detective controls include logging and monitoring to be able to collect and analyse security logs and other events. It is important to identify threats, but also the effectiveness of the Devsecops processes such as the time to take to fix a discovered vulnerability. Having the appropriate contacts into the different security teams is also effective for escalating issues to, for example, incident response or receive news from the threat intelligence team.
Security Testing and Quality Assurance is critical and to a degree already occurs, in addition it is possible to integrate security testing tools into the development pipeline (Continuous Integration/Continuous Deployment). This can include vulnerability scanning, penetration testing, or container security scanning. Finally guides to help teams securely configure all the tools and capabilities making up the CI/CD pipeline, there is no sense writing secure software if the development software itself is insecure!
Overall, the approach is small iterative steps over a long period of time, having milestones, remembering there is no end destination. Things to avoid are large long winded security projects, these are an instant stop for developer, confusing and overcomplicated tools that distract developers from developing is also something else to avoid.
Supply chain security, protecting dependencies from compromise is a huge challenge right now, learn how to detect and prevent your organisation from supply chain attacks by watching my course on Udemy:
Software Supply Chain Security for Developers
