Every day seems to bring news of yet another high-profile security incident at yet another well-known company, and we know that many more such incidents go unreported. As bad actors grow ever more sophisticated, responsible IT organizations also need to become more sophisticated in how they protect themselves.
Moving your security work earlier in the development process, for both code and infrastructure, is a vital part of mitigating financial, legal, and reputational risk. This strategy of moving work earlier in the software development lifecycle (SDLC) is often referred to simply as shifting left.
Shifting security left means that security can no longer be solely the province of dedicated security professionals brought in just before a release. Instead, an entire range of teams needs to be brought into the process much earlier. The aim is a holistic approach that involves the appropriate stakeholders throughout the entire SDLC.
Security From The Very Start
Ideally, security should be incorporated into the design and requirements phases. Many high-performing engineering teams are doing just that. Done properly, the ROI of a shift left approach is significant. It can make the development process easier and faster, and save money over time.
In shifting security left, application software developers will find themselves collaborating with new groups and adding additional checks to their work. This may seem like extra work, and in many ways, it is. But over time, shifting security left shouldn’t be that different from shifting testing left. Sure, testing is still its own stage in the SDLC, but test-driven development now permeates all parts of the SDLC.
With the increasing adoption of a DevOps/automation approach, it’s become somewhat easier to involve all parts of the enterprise in shifting security left. But it still takes work and collaboration to be effective.
This post discusses who should be involved in shifting security left, and gives a peek into what their new worlds will start to look like. You can see a developer-only approach to this shift in my recent post for Stack Overflow.
Who Should Be Involved?
Security vulnerabilities can affect the entire organization. Shifting security left impacts a wide range of teams as well. Integrating security tools and best practices into areas where they haven’t traditionally been used requires new levels of collaboration, necessitating a holistic approach. A short list of key players includes::
- DevOps
- Application Developers
- DevSecOps
- IT
- Security
- Governance
Let’s cover each team’s primary responsibilities in more detail.
DevOps
As the DevOps team provides overall governance of DevOps culture and practices, its engineers and leadership should ensure security is treated as a first-class concern in the SDLC. This team often takes on the nuts-and-bolts work of securing the infrastructure that applications run on, by building security assessments and feedback systems into their automated pipelines.
Application Developers
Adopting a shift left approach affects those already furthest to the left in the SDLC: application developers. This team, tasked with designing, implementing, and testing the code behind the application, has a critical role to play as an organization shifts security left. Developers need to adopt secure coding best practices, such as using IDEs with linters and source control tools, and properly securing access to codebase repositories. It’s also a good idea to consult the list of the top 10 web application security risks published annually by the Open Web Application Security Project (OWASP).
The application development team can also establish a testing methodology that introduces automated and comprehensive testing earlier in the SLDC. Some of the checks that developers may need to add to their work include:
- How do I make sure code is secure and written to spec?
- What does communication look like between containers?
- What do APIs look like for various systems?
- What external APIs am I consuming?
- How do I minimize my infrastructure’s software attack surface?
- How do we know what systems need to communicate?
- Can we visualize these communication patterns in a map or a sequence diagram?
Shifting left also means raising awareness of the dependencies used to build an application—in particular, open-source dependencies. This is where strategies such as static application security testing (SAST) and dependency tools such as GitHub Depandabot can be helpful. Working closely with DevOps and DevSecOps, the application development team can help prevent the introduction of security vulnerabilities through the software supply chain.
DevSecOps
DevSecOps teams can best serve this shift left approach by driving the adoption of security best practices from the very beginning of the SDLC. Often this involves significant work on the automation tools used to build, deploy, and maintain applications. But it can also mean collaborating at earlier stages, and envisioning scenarios that consider security concerns right from the start.
DevSecOps can also provide comprehensive monitoring and analysis services that help create secure infrastructure and code. Done in concert with a DevOps strategy, this can be an invaluable tool for identifying issues early.
IT
Many organizations struggle to persuade engineers to place a premium on building code with security threats in mind.
As the people that manage the tools to be used by the application developers,, the IT department also needs to create security-conscious development practices. This means both encouraging the adoption of security tools early in the development process and working hard to reduce the friction that such tools might create in day-to-day engineering work. If a security tool slows developers down too much, you can bet they’ll find a clever way to avoid using it.
IT should investigate and adopt tools that allow engineers to easily create secure code, without adding excessive overhead to application configuration and build/test processes.
As a shift left approach gains traction, IT also needs to consider the impact of automated security assessments. These assessments often significantly extend the build process time, resulting in an automated pipeline with backlogs. IT departments may need to make strategic decisions about what really should be tested in development environments, while still creating trust in automated processes.
Security
The security team possesses deep knowledge and skill in areas that many engineers only understand at a surface level. In a successful shift left program, security pros will need to act as subject matter experts for application and infrastructure security, advising developers – and everyone else – on best practices.
This often means the security team will need to provide tools and training to enable the organization to easily integrate protection throughout the SDLC. It’s important that any barriers to adoption of these tools are as low as possible, as not everyone will immediately appreciate the importance of changing work patterns in a shift left approach.
Governance
Because of the influence that the governance team can have over every aspect of an organization, it plays a key role in launching a successful shift left approach. Governance should work to integrate security awareness and best practices into overall IT strategies and implement those practices throughout the organization.
With their comprehensive understanding of how the various departments operate, the governance team is best-positioned to advocate on behalf of the overall development effort, communicating the importance of security–and of shifting left–to leadership.
Getting Started
As we’ve seen, shifting security left requires cooperation from across your organization. As in any other broad-based attempt at change, executive sponsorship is critical.
One successful strategy is to establish a shift left working group that includes representation from all stakeholders. Such a group might:
- Survey existing security practices and tools: “What are we doing now?”
- Ask DevSecOps/Security experts to assess the existing security posture and identify high-priority risk areas: “How effective is our current approach, and where is it letting us down?”
- Create a shift left strategy and communicate it clearly: “What are we going to do about it, and how do we talk about it?”
- Identify low-hanging fruit—those best practices or tools that can be most easily implemented and which will demonstrate clear ROI to leadership: “What can we start with that will show the value of our approach to shifting left?”
A shift left security approach is becoming essential, not optional. Organizations need to have an attitude of “when, not if” a significant security attack will occur, and they should make security a first-class player in every part of the SDLC.
The most successful approach will involve collaboration among multiple groups within your organization. To gain wide adoption, the approach will require a clearly stated strategy along with easily implemented tools and processes. And it’s key to use a common tool or dashboard so that everyone can communicate clearly, avoiding confusion. The payoff: confidence in your security posture and the freedom to innovate without fear.
Join our daily livestream from the DevNet Zone during Cisco Live!
Stay Informed!
Sign up for the DevNet Zone Cisco Live Email News and be the first to know about special sessions and surprises whether you are attending in person or will engage with us online.
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
LinkedIn | Twitter @CiscoDevNet | Facebook | YouTube Channel
Very informative. Thank you.
I’d like to start and finishing/working on this shift left security.