When creating software, what do you think about?
Probably, your top priority is quickly delivering new features and satisfying customer needs. And that means choosing the right architecture and tech stack so that it’s robust, scalable, and easy to maintain.
Anything else? Do you think about security? Of course you do. But according to this State of DevOps Report presented by Puppet, CircleCI, and Splunk, a lot of companies don’t think about security properly; they integrate it into their software only occasionally and non-systematically.
Why does this happen?
Probably because security is an invisible feature that is hard to sell to the customer. Further, most organizations assume that security is an expense (and thus, should be at the minimally-required levels), and that it’s only a concern if a breach occurs.
But this perspective is incorrect. Your project could benefit greatly from “shifting security left,” that is, earlier in your SDLC; among other benefits, you’ll save money, you’ll save time, and you’ll enhance your reputation and position in the market.
In this article, we’ll discuss why and how this works.
What Is SDLC?
“SDLC” stands for “software development life cycle”: a process followed by a particular software project, within a particular organization. This definition implies that SDLCs differ among projects and companies, but some common phases can include:
- Analyzing requirements
- Designing the architecture
- Implementing the architecture
- Testing
- Shipping the product
What Is DevOps and How Does It Change Your SDLC?
The DevOps approach is often used in the context of the implementation, testing, and deployment phases of an SDLC. AWS—pioneers in this field—define DevOps as a “combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.”
From a practical point of view, DevOps is based on using tools and technologies like:
- Infrastructure as code, containerization, and orchestration
- Configuration management
- Test automation
- Continuous integration and delivery
- Metrics and monitoring
Following DevOps practices will have a positive impact on your product. First, it shortens the SDLC, i.e., your software flows through development faster. As a result, you can increase the deployment frequency and shorten your time to market. Also, releases fail less often due to enhanced testing and CI. Finally, metrics and monitoring allow you to find bottlenecks and issues in your software and recover from them faster. Your organization can also use those metrics to refine requirements and pass them along to your architects to design better software, thus, improving your entire SDLC loop.
Where Is Security in This Picture?
The State of DevOps Report mentioned earlier defines five possible levels of security integration in an SDLC:
- No integration of security in any of the phases
- Minimal integration (one of five phases)
- Selective integration (two of five phases)
- Significant integration (three or four of five phases)
- Full integration (all phases)
The surprising result of the survey (see page 30 of the Report) is that more than half of the respondents stated that security is only occasionally integrated into their SDLC (levels 1–3). And almost one-quarter of the respondents think about security only in the last two SDLC phases—testing and shipping.
That’s too late! As discussed in-depth in this OWASP Web Application Security report, truly secure software is a result of keeping security in mind throughout the whole process, starting with the earliest stages of your project.
One of the frameworks that helps to clearly define security in software applications is the CIA triad: confidentiality, integrity, and availability.
Confidentiality means that the information in your system is not disclosed to those not authorized to access it, while those who have authorization may access it freely.
Integrity is about ensuring that data can’t be changed without being noticed. Imagine you digitally sign a contract, and later, your counterpart wants to imperceptibly change its conditions. Digital signatures make this impossible; this is what integrity is about.
Availability guarantees that information is available to those (who, of course, have the authorization to access it) when they need it. In practical terms, it means that a system is protected from denial-of-service and similar attacks.
It’s your job to follow these principles using security requirements, which can come in three forms:
- Functional security requirements can be directly observed and tested, like “unauthorized users cannot see this.” A simple test case can check if the requirement is satisfied: First try to access the data as an authorized user, and then do so anonymously.
- Non-functional security requirements describe related system behavior. Continuing our “unauthorized access” example, a system may “need to log all the unauthorized access attempts.”
- Derived security requirements are those requirements that are implied from the functional and non-functional ones. In our example, this would mean the system should have logging and reporting capabilities.
DevSecOps and Shifting Security Left
Usually, companies emphasize functional requirements, but all of them are equally important and contribute to your project’s security posture. If you add these requirements to the first stage of your SDLC—requirements analysis—and follow them throughout the process, the approach you’ll get as a result is called DevSecOps. This is called “shifting security left.”
This shift brings a lot of benefits to your project; let’s look at the most important of them.
Benefits of Shifting Security Left
First, you’ll save money. This presentation discusses the costs of fixing defects in software. Slide #10 gives some numbers: Fixing a defect during a shipment phase is 160 times more expensive than fixing it during the development phase (unit test) and 16–60 times more expensive than fixing it during the test phase! Upgrading a dependency library to include the latest security checks costs almost nothing—probably a few hours spent by a single engineer—compared to the potential damage of shipping a release that contains a security hole.
You’ll save time. Of course, time is convertible to money, but let’s separate the two. The same principle applies to the amount of work: Vulnerabilities discovered and eradicated earlier eliminate security bottlenecks from occurring in the final stages of development, thus saving your engineers time.
Your customers will trust you more. As stated previously, security is not always visible to customers. However, inadequate security will eventually become apparent. Having a stronger security posture than your competitors—i.e., providing secure services when others fail—is how you gain trust and grow your customer base.
Your team’s confidence grows. According to the State of DevOps Report, “integrating security deeply into the software delivery lifecycle makes teams more than twice as confident.” And a confident and happy team will tend to be more productive.
Best Practices
Even though systematic approaches to project security are fairly new, some best practices have already been developed by companies and organizations such as Google, Reblaze, OWASP, Splunk, and others. Below, we cover some notable ones.
Follow the principle of minimal privilege when designing a system. No human or part of the system should have more access than needed to solve its task.
Have your codebase covered with static code analysis and unit and integration tests. A lot of security problems are caused by simple issues like off-by-one errors or accepting unsanitized user input. You can effectively troubleshoot these using tools like JUnit, FindBugs, and SonarQube. These checks are relatively cheap to introduce, and there are plenty more options than listed here.
Identify and prioritize potential threats among dependencies and your codebase using services like Snyk or GitHub’s Dependabot.
Watch the Common Vulnerabilities and Exposures (CVE) index, and update your software and dependencies regularly. Always keep an eye out for the latest updates for the tools, libraries, and frameworks you use. Sometimes fixing a security vulnerability is just a matter of updating your dependencies. Snyk and Dependabot do that as well.
Conduct security reviews on every phase of your SDLC. Listen to your security team during the requirements analysis and design stages; make sure they take part in the development process by providing feedback for major features.
Develop a collaboration culture in your company to reduce friction during these security reviews. Your teams should not treat each other as enemies; instead, they should be working together.
Put your security under question by testing it. You can use your own security team to conduct pentesting, a third-party consulting company, or even individual “white hats.”
Challenges of Shifting Security Left
Of course, everything comes with a price, and improved security is not an exception. The DORA State of DevOps research program gathered a lot of case studies and compiled a set of challenges that have prevented teams from shifting security left.
The first challenge is that this approach requires mature teams. Teams with low to medium maturity face more struggles when introducing security in their SDLC. And in general, to start thinking about security in your project systematically, you first need to have some sort of systematic approach to developing the project. You cannot introduce good security practices in a project that doesn’t follow some basic best practices, like having high test coverage and CI.
Another challenge is your developers’ awareness of security risks. Many developers are not used to thinking about security; some have never even heard about OWASP’s Top Ten. Security training and checkups should become essential when shifting security left.
DevSecOps can introduce friction between your developers and operation and security teams, as more collaboration is needed between them to achieve the goal. Their intentions are fundamentally different; a developer’s job is to introduce new features into the project, but these can include potential vulnerabilities, and your security team’s job is to prevent that from happening.
You’ll need to make sure that the security team is engaged in your SLDC at all stages and in a substantial way. Security teams are often understaffed and unheard by others—this must be fixed.
A common objection is that introducing security will slow down your SDLC, simply by introducing more work. But, in highly evolved teams, this won’t be that much, and the overall time savings will outweigh this cost by means of features such as automated incident responses.
Conclusion
This article has discussed the practice of shifting security left. The basic idea is simple: to consider security while developing software. Unfortunately, many organizations are still failing to reap the benefits that this practice brings; if yours is currently among them, hopefully this will change soon.
Building security into the SDLC is an important part of a robust security posture. However, it is not the only part. There are many forms of web attack that do not rely on direct exploits of the targeted web application; for these, you still need a robust web security solution. Reblaze is a unified, all-in-one solution with a comprehensive set of security technologies: next-gen WAF, DDoS protection, biometric bot management, advanced rate limiting, ATO (account takeover) protection, API security, and more. Regardless of how far left you have placed security in your SDLC, Reblaze can protect your sites, services, applications, and APIs. For more information, or to get a demo, contact us here.
