Development teams and security teams have traditionally had their own silos, their own functions, and their own tools and language. Developers create applications, and security teams do their best to break those applications.
As developers moved from waterfall programming to extreme programming to DevOps, however, those silos broke down. The recognition that it is best to catch vulnerabilities and design weaknesses as early as possible has fueled a shift in responsibility for security from app sec teams to every member of the DevOps pipeline.
Yet companies still have difficulty in shifting security leftward, earlier in the development process. Here are best practices to help your teams shift security left and build more secure and resilient software.
1. Know the past
For many decades, the common approach to software development was a lengthy process of establishing requirements, creating a design, programming the application, verifying its function, and establishing a regular maintenance cycle. Known as "waterfall," because of the way the requirements trickled down through software development, the process typically didn't involve security until the verification step, if it was considered at all.
As a reaction to the long feedback loop and slow development times, a more agile form of development was established in 1996 and dubbed "extreme programming" by creator Kent Beck, with 12 core practices, including defining user stories, producing minimum viable products, using simple code, and doing frequent refactoring. This approach relied on feedback cycles, repeated often and quickly, to speed development and get code into deployment as soon as possible. Eventually, the agile concepts were codified in the Agile Manifesto, published in 2001, with Beck as one of the 17 signers.
DevOps arrived in 2008, credited to a discussion between Andrew Clay and Patrick Debois and incorporating deployment and operations into the development pipeline. In 2013, the book The Phoenix Project cemented the role of DevOps as a trend in IT development. Developers, testers, and operations finally became friends.
2. Embrace the cultures
Yet security has typically not become a team member. While agile accelerates the delivery of functional software, DevOps focuses on enabling developers to have a role in deployment, operations and test automation enables early detection of bugs and automated deployment prevents human errors. All are part of continuous integration and continuous delivery (CI/CD), and they do reduce the chance of vulnerabilities, but security has not always been a priority in the development cycle.
The culture of DevOps, however, is about improving the software lifecycle and reducing the complexity of maintaining software. Security needs to be a part of that. Security champions can help by bringing together developer and security mindsets so that the two roles can better understand each other. In addition, the DevOps emphasis on responsiveness means that teams have to also quickly respond to changed security information and context.
3. Share responsibility
Developers are not just responsible for writing code, but must accept wider responsibility for that code as well, from inception to end of life. Part of that responsibility is to produce secure software. As early as 2012, ruggedsoftware.org tried to address the problem of writing available, survivable, defensible, secure, and resilient software.
Unfortunately, security responsibility still today is often pushed onto a DevOps team member, known as a security champion, rather than shared across the entire team. The security champion is the one who has to validate the huge amount of security issues and usually is required to—over and over—explain to the team what a SQL injection is and why developers should not use string concatenation to create an SQL query.
Shared responsibility is about software developers' craftsmanship, encompassing code quality and security. By shifting security left, the security team can focus on finding the more complicated functional or multi-stage security issues and on monitoring and mentoring the teams on the latest threat category trends and guide toward solutions.
4. Tools, automation, and dashboards
The fundamental misperception about security-testing tools is that they are to be used only by security professionals. They are not. They are developer tools, designed to help programmers and coders detect vulnerabilities in their software as early as possible.
The process of code analysis using static application security testing (SAST) tools, for example, should be done automatically as you write in your editor. Software composition analysis (SCA) should be part of your test strategy, to prevent insecure dependencies being included in your deployment. Dynamic (DAST) and interactive (IAST) security testing can be done during staging to catch errors that avoided earlier detection. All that can be easily enabled with the CI/CD emphasis on automation.
The integration of secure test automation must become common practice along with other code-quality tool integration—a responsibility that should lie with the engineering group that builds the development pipelines, not the security team.
The same applies to the vulnerability management systems, which often are managed by security teams. DevOps teams already have the expertise to run and maintain such applications. Rather than deliver PDF reports to the developers, the results of any application security testing should be integrated in a dynamic dashboard, aggregating and correlating the findings from the various (automated) tools.
Those dashboards must give a holistic view of your whole software asset management and enable risk management by providing the DevOps team with early feedback, the moment they write code. Integration and automation capabilities are key.
5. Continuous improvement
Finally, to prevent future mistakes, developers need to not just use the tools, but also understand why they are using the tools. If we know the reasons and context behind security measures, we can do a better job. That means developers, who require quick results with preferably no false positives, need to recognize that enterprise-quality applications also mean no false negatives.
Different testing streams per application and application lifecycle are mandatory. So are a stream for testing your inbound third-party source code, libraries, and other external dependencies; a stream of quick-run tests to verify your in-house code and that satisfies your developer’s needs; and a stream of more time-consuming, but more in-depth, tests to enable enterprise-level security validations.
No matter the development process—waterfall, extreme programming, agile, or DevOps—no one can deliver 100% secure software. You must recognize that any technology, framework, or library thought to be secure today could have a zero-day exploit tomorrow.
Doing continuous security testing and monitoring early in the software lifecycle is leveraging the responsiveness of DevOps in order to continuously improve security. A vulnerability management system with a dashboard for a holistic view of your software assets and application landscape supplies real-time and up-to-date information about your application, and it is essential to know the application's "bill of material" in order to know what to respond on and where to focus.
No silos allowed
When security decisions are understood by developers and development decisions are understood by security leadership, both sides can work better to prevent vulnerabilities and efficiently and continuously use tools and automation to identify security issues early and often.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
