Delivering features quickly and shipping quality, secure software can sometimes seem like incompatible goals. To get there, we need to bring security into the modern age.
As the world goes digital, the demand for software is surging. Every aspect of our lives is becoming digitally connected. From the watches on our wrists, to the cars we drive, and the way we purchase goods, more and more of our lives are served by digital, connected experiences.
To deliver on this, companies are increasingly embracing digital transformation – requiring more and more APIs, front-end interfaces, microservices, data pipelines, and ML algorithms. The demand for software and features is growing at a break-neck pace.
Product development teams have adopted cloud computing platforms and modern software frameworks to speed up delivery. They’ve embraced approaches like The Lean Startup to reduce the time it takes to find the right mix of features that customers want, and Accelerate to optimize their software delivery approach. All these efforts are in the name of delivering the best features as fast as possible to drive growth and customer engagement.
Unfortunately, a consequence of leading increasingly digitally-connected lives is compromised security. We frequently see reports of large-scale security breaches that can lead to identity theft, negative impacts on brands and consumer trust, negative financial impacts on individuals and businesses, and even terrorism and all-out cyber warfare between nations.
The security of the software and data that powers digital experiences is increasingly at risk.
Traditional security approaches aren’t working
How are technology organizations responding to the threats? Well, many are simply crossing their fingers and hoping nothing bad will happen.
Maybe they’re asking their engineers to take an online security training once a year. Some organizations, especially those in regulated industries where they need to be SOC2 or PCI compliant, are hiring consultants to do a security audit once or twice a year. And while larger organizations are staffing in-house security teams, typically those teams are relatively small compared to the size of their software development teams. And those development teams are growing while the security team is not.
While software development teams are shifting into the fast lane, conventional security practices are stuck in the slow lane, with the right blinker on. If an organization does periodic security audits, engineering leaders have to figure out how to respond to what can be a daunting list of vulnerabilities they are asked to address, while still delivering the features they’ve committed to. So they will likely choose to do the bare minimum.
Even if a company has an in-house security team, many security professionals struggle to make a significant impact in identifying security vulnerabilities quickly enough and getting product and development teams to prioritize fixing them. Vulnerabilities are typically found late in the software development lifecycle, frequently after software has been deployed to production. At that point, the development team has already moved on to something else. It can feel like a losing battle.
While some security organizations have created robust incident tracking systems, ways to assign issues to development teams, and try to enforce SLAs for remediation, those approaches are time-consuming to set up and fraught with political turf wars.
In the end, any approach that seeks to slow down the rate of change is destined to be ineffective, as the insatiable desire for more and faster features will always win out. Economic expansion is just a stronger force than the desire to avoid risk. It is a losing battle, and security efforts are likely to be left in the dust.
So as they say, if you can’t beat ‘em, join ‘em!
It’s time for a different approach to delivering secure software, one that’s better aligned with the pace and strategy of modern development teams.
Five ways to shift security left
In order for security to shift out of the slow lane and into the fast lane, a transformation needs to take place. Comparable transformations have happened in the areas of QA and operations, where traditional roles and manual approaches have changed, enabled by new technologies and dev-centric automation. Organizations and security teams, in particular, need to similarly embrace newer tools and automation, put more control into the hands of people writing code, and enable them with training and support. Some call this trend ‘shifting left’.
This transformation requires traditional security folks to change how they think about their jobs. They must evolve from doing all the legwork of finding vulnerabilities and tracking tickets to working on integrating modern tools with build and deployment pipelines, educating software developers on how to avoid creating security vulnerabilities and how to best fix them, and validating that good decisions are being made.
So, how do you shift security left? Here are a few practical steps:
1. Start using security tools that are built for developers
The three main categories of security testing tools are Software Composition Analysis (SCA), Static Application Security Testing (SAST), and Dynamic Application Security Testing (DAST).
SCA tools will tell you whether there are known vulnerabilities in the code libraries that your software uses (for example, the recent Log4Shell vulnerability was found in a version of the popular Java Log4J logging library). An SCA tool scans your codebase for dependencies and alerts you if you need to update or replace one of those libraries. A well-known developer-friendly SCA tool is Snyk.
SAST tools will analyze your code and look for patterns that resemble security vulnerabilities, while developers are working in the code. They can point developers to the exact line of code that is problematic, so they can fix it before they deploy their changes. On the downside, these tools are language-dependent, so they may not have support for the programming language your developers are using, and they tend to result in more false positives since they don’t observe the running application. Snyk also offers a SAST tool.
DAST tools interact with your running application. They send malicious inputs (similar to how a hacker would attack your app) and inspect the outputs, looking for signs of vulnerabilities. DAST tools – like StackHawk – are language-independent and have lower false positives since they are observing actual evidence of an exploit in the running application.
Do you need all of these tools? Not necessarily. A good place to start is with SCA and DAST, which give you the coverage to detect known vulnerabilities in your software libraries and unknown vulnerabilities in your code.
My advice? Have your developers help you evaluate these products. Select tools that are developer-friendly, as many of the legacy products in this space are instead more focused on enabling traditional security teams to scan production systems. Make sure they are easy for developers to configure, use, and integrate with your build and deploy systems.
2. Baseline your applications
When you first start using these tools, you need to go through a period of baselining – reviewing findings, deciding what you need to fix right away (hopefully the high severity issues), and either putting any remaining issues in your backlog or marking any False Positive/Risk Accepted if you decide there are some you don’t need to address. This way, when new issues pop up your developers will know they need to pay attention, triage, and potentially fix, without having to worry about any noise in the results.
Baselining requires that you give your development team time to understand and address the important issues that may exist in your software. Depending on what the security tools find, you may have a hole to dig yourself out of. Make sure you allocate time in your planning process to improve security.
3. Automate security scanning in CI/CD
This is where the magic happens. After you’ve baselined your applications, you should hook your security tools up to your build automation (CI/CD) pipeline. From this point on, when a developer pushes up a code change, your security tools will automatically scan that version of the application. They can alert developers of new issues and even block the build from moving forward if serious issues are found.
Now you’ve shifted left! You’re catching security vulnerabilities before code is deployed to production, and developers are alerted to them as they are working on the code – not later. They can quickly fix the issue, just like they would react to a broken test. This reduces the cost of finding and fixing security issues, and reduces the risk, as they are being found before changes are deployed to production.
You can think of this just like running a suite of automated integration tests. These are just a suite of security tests, and any failures are security bugs that developers need to fix!
4. Train and trust your developers
Did I say trust developers? This can be a crazy concept to folks with traditional security backgrounds. But it’s necessary in order to shift left. You need developers to learn how to use these new-fangled security tools, interpret the results, fix vulnerabilities, and ultimately, prevent creating them in the first place. A good developer-focused security tool will help you with this. Look for tools that have developer-friendly explanations and links to resources on how to fix vulnerabilities.
Some security professionals might bristle at the idea of trusting developers with security. When similar transformations were happening in QA and in operations, leaders with traditional backgrounds had similar concerns and objections: ‘Developers don’t know how to do quality work,’ or ‘developers don’t understand how to build infrastructure.’ But those shifts have occurred, and have been largely successful. Developers can learn how to handle security testing and remediation if they’re given the knowledge and tools – and yes, trust – to do so.
To support this transformation, the roles of traditional security folks need to shift to delivering training, setup, and support of tools and automation. And they need a stance of ‘trust, and verify.’ It’s perfectly reasonable for security teams to have an oversight role to ensure that development teams are making good decisions with these new security testing tools, perform audits, and make sure production systems are properly monitored.
5. Fix your organizational alignment
Finally, transforming how your company does security work and getting into the fast lane requires organizational alignment. If your company has a security team, do the leaders of security and engineering report to the same leader? Do they regularly talk to one another? Do they have shared goals? If not, start making changes. Anything you can do to align engineering and security teams’ leaders and goals will help you achieve this type of transformation, and ensure it will be successful.
Security and engineering teams should cross-train one another. It’s beneficial for security professionals to learn about software architecture, how developers build and deploy software, agile planning, and the day-to-day process of development teams. And it’s also good for software engineers to learn more about security exploits, how their systems can be hijacked, and how to defend against it. Getting a security professional involved in architecture reviews before a single line of code is written can help you shift even farther to the left. And coming at it with an attitude of support and collaboration can help build lots of goodwill.
It almost goes without saying, but frequent, honest communication is key. If something isn’t working well, give honest, direct, but kind feedback. Assume good intent. Build bridges. Avoid political gamesmanship. Build relationships and be friendly.
Ready, set, go!
Security threats aren’t going away. And the appetite for digital experiences and the software to power them will only continue to accelerate. Bringing security into the modern age of software engineering is not only possible, it is a reality, and more and more organizations are doing it. It requires a shift in thinking, adoption of new tools and automation, organizational alignment, and support to be successful. Whether your organization is primed for this type of transformation or has a lot of work to do, the best way to get started is to start. Get into the fast lane and step on the gas!
