We have come a long way in the DevOps lifecycle, from releasing the code every month(or sometimes more than that) to every day(or every hour). Throughout this process, it feels like security has been left behind a little. The main reason behind that is, security will slow down the DevOps Lifecycle and the entire software pipeline.

‘Shifting security to the left’ is a popular term in the and , which means considering security during the entire SDLC and not just in the final stages. For example, if a developer uses some external third-party library in the code, and we follow ‘shift to the left’ then, instead of waiting till the end to find and resolve any potential vulnerabilities, we can fix them much earlier when these issues are less expensive.

Shifting left doesn't mean we don’t need any security testing before the production release. We still need all the traditional measures and secure development practices. It is just that it will act as a final check before the release.

Still not convinced? Refer to the State of DevOps Report, presented by Puppet, CircleCI, and Splunk here.

Many companies give lesser importance to security. Security is integrated into their software occasionally. One of the primary reasons for this is that security is a complex feature to sell to the customer. Most companies only think about security once the breach occurs. Since security also requires some initial investment, the least amount of effort is put in, but this perception is wrong.

Since shifting security to the left has benefits like catching issues at an earlier stage, it helps the company save time, and money and enhances their market reputation. In this blog, we will discuss how this works.

Introduction to DevSecOps

DevSecOps makes security a part of the Development and DevOps lifecycle to facilitate early feedback. Security can't be a bottleneck, and it must be integrated at every step of the software pipeline, from development to release and monitoring. We need to use the right set of tools at every stage to make that happen.

In the past, the security teams worked in silos and contributed to the final stages of the development process. This works well when we have a project which lasts for months or even years. Here, we can have a security person or a team who approves changes at every step. For example, if a developer brings some external third-party library into the code, the security team needs to review and approve it. The new DevSecOps model facilitates automation at every layer and doesn't require any manual intervention. As most companies have pressing needs to release a new product in the market, they can't wait for manual and lengthy security reviews, so we must incorporate security within the DevOps pipeline. The key is to use the right tools at every step in the development and operations phase.

How to implement the Shift-Left approach in your organization

There are two key phases to implementing the Shift-left approach in your organization. They are:

Planning

Planning is key to any successful implementation. You must establish a clear threat model and acceptance test criteria. You must define your end goal and what shift-left means to your organization. At every stage, there is a document that establishes responsibility and ownership, like who and which team owns which piece. There are clear metrics backed by data after reaching each milestone.

Implementation

Once you have a clear plan, the next step is the implementation phase. The key implementation factor is automation. The more you automate, the more you accelerate your SDLC process and reduce human error.

The question is, which tools can be used to shift security to the left in your organization? On top of that, all the tech stack you choose needs to be carefully implemented and successfully integrated without creating any security gaps or bottlenecks. The bottom line is whatever tools you choose, security is now a part of every phase.

Let’s take a look at some of the tools we can use:

• Development Tools: The first step after planning is development. We can use Integrated Development Environment(IDE) with security plugins to scan for known vulnerabilities. In some cases, they also trigger a manual code review if a large code change is detected. We can also use a solution like a pre-commit hook so that developers can't check in any code which contains authentication keys or passwords.
• Code Repository: Now, the developer needs a centralized place to check his code. For source code repositories, you can use GitHub, BitBucket, or GitLab. Again, we can implement a repository and perform a secret scan to ensure there is no vulnerability and no secret is accidentally checked into the code. These are usually fast scan checks whose aim is to give quick feedback to the developer.
• Continuous Integration/Continuous Delivery Tools: Once you check your code in a centralized repository, the next step is to ensure if it's working as expected. At this stage, your CI/CD solution is the key as it orchestrates all the moving parts and ensures that everything is integrated correctly and automated to make the magic happen. For CI/CD, we have solutions like Jenkins, Travis CI, TeamCity, or Bamboo.
• Code Build: The next step is to take your code and build it. You can use solutions like Ant, Gradle, Maven, and CMake for the build. Once the build step is complete, we need to store artifacts securely created as a part of the build process or by any third-party and custom libraries. We can use solutions like Artifactory, Maven, or Nexus. At this stage, you can digitally sign your artifacts for greater security.
• Testing: Testing is always a key component and automates unit, functional, regression, and integration tests. Solutions such as Cucumber and Selenium enable you to run tests before deployment. At this stage, we are again performing security testing to uncover any vulnerabilities, threats, and risks in the application. This is the testing that will be performed once the code is deployed.
• Code Deployment: Once your code is ready and CI/CD test is passed, the next step is to deploy your code. If all of the previous checks were completed successfully, it's now time to deploy your code. For that, you need an infrastructure where you can deploy your code. The most viable option is cloud providers like AWS, GCP, and Azure. You can also use containerization solutions like Docker with Kubernetes, which allows you to orchestrate and manage these containers at scale. Before deploying the code in production, most companies have a staging environment where they can perform penetration testing, aimed at simulating the cyberattack and whose purpose is to evaluate the system's security. You can use solutions like Puppet, Ansible, or Chef for code deployment.
• Code Scanning: The most crucial component lies in every step of your SDLC security. You can use tools like SonarQube and Nessus to scan your code for vulnerabilities and your containers for any open ports.
• Monitoring: Once your application is deployed, you need to monitor it. For that, you can use solutions like Nagios, Splunk, ELK stack, or New Relic. Here we set the security threshold and a notification to receive an alert if a certain threshold is reached. You can identify the type of traffic your website is receiving and get an alert if you see any anomaly. This will help you stay ahead of the curve by identifying bugs during the early stages.

The advantage of Shifting Security to the Left

Shifting security to the left has some key advantages:

Making developers implement more security-aware solutions: In the earlier model, the security team implemented security tests as a part of the CI/CD pipeline. Most commonly, they had a post-build step via the Jenkins pipeline, which checks for any security issues. Designing and implementing such a solution in a pipeline will sometimes take a month, but if you can shift the developer's responsibility, it will be much easier for them to implement it and make them more security-aware.

Spot Issues, Bugs, and Vulnerabilities earlier: A developer can rapidly integrate the testing results into their code and get the working code in production sooner. The advantage of this approach is that every check needs to go through a series of security checks before being accepted into the build. A developer can quickly address any issue as all the changes are fresh in his mind. In contrast, during the traditional approach where vulnerability is found during the later stage, changes may not be fresh in the developer's mind and may take time to resolve.

Using Open Source solution with increased confidence: Since the open source community welcomes contributions from anyone, it opens the door for abuse by a malicious actor. Your developer is unknowingly using this malicious library without knowing its impact. By shifting left, we have scanning tools in place that constantly scans your project and point out malicious open-source component.

The disadvantage of not Shifting Security to the Left

Fixing the security vulnerability close to the production release has some significant drawbacks. If any major vulnerability is found, you need to answer tough questions like:

• Can we delay the release?
• Can we apply a hotfix?
• Can we go live with the vulnerability and fix it later?

Late detection of fixing security and quality issues will be a costly affair(as developers need to spend an entire cycle fixing it, they will face loss in customer trust and brand value), especially in production.

Challenges

Cultural challenges

As security always lies on the spectrum and is an afterthought in many organizations, shifting security left will be a drastic change. This is one of the major roadblocks and discourages organizations from shifting left.

Slow Innovation

A common myth is that shifting security left will slow down the innovation process. As security is now implemented at every SDLC layer, it will slow down things and lead to innovation barriers.

Training your existing team

The developer, operation, and security teams collaborate in the traditional model. The developer and operation team follow the security best practice, but they don't own the security. Now the mindset needs to change as security is everyone's responsibility.

Wrapping up

Is security everyone's responsibility? This is one question that has been asked in all organizations at every level. This becomes more challenging and complex due to the faster release and adoption of your organization's open-source component, but at the same time, data security is getting stricter. Shifting security to the left will eventually speed up the development process and help in early detection of bugs.