Guides

Shift Left Security

Shift Left Security in Practice: Process and Tools

What is Shift Left Security?

Software development is a process involving several phases, including design, development, testing, security, and release. Traditional software development methodologies perform these phases one at a time, typically leaving security to the very end. This type of methodology does not allow for an early discovery of security flaws, makes it difficult to remediate security issues, and in the end, results in software that is less secure.

Shifting security to the left means introducing security early on in the development pipeline. The goal is to detect issues quickly, when they can be easily fixed. When security, performance, and availability issues are detected after the product is complete or released, remediation can turn into a time-consuming and expensive process. Oftentimes, these issues are only discovered in production, which in the case of severe security flaws, can be catastrophic.

Development teams can achieve better results by incorporating security into their daily work, rather than testing for security at the end of the process. This is often done as part of an organizational structure known as DevSecOps, which unifies the DevOps and security teams.

Today’s teams are agile and operate at high velocity to release new software versions daily, or even multiple times per day. Security can be built into this process with the help of automation. By introducing security automation into the process, teams can shift security left, without worrying about slowing down the pipeline.

 

In this article:

 

What are the Benefits of Shift Left Security?

Security issues often “snowball,” starting as a small issue—perhaps a small programming mistake—that later becomes a severe issue that requires major efforts to fix. A recent study showed that over 70% of vulnerabilities shared on HackerOne, a bug bounty platform, were caused by simple errors like failure to implement URL checks.

Shift left security allows developers to identify and fix security issues when they arise. This can dramatically reduce the effort involved, and also helps with agile planning. It is easier to plan smaller security tasks in earlier stages of the development process than to allocate time for unexpected security reviews and large fixes at a later stage.

According to the National Institute of Standards and Technology, the labor cost in hours of bug fixes is almost zero if the issue is caught at the requirements stage. It increases by 10X at the coding stage, and by as much as 30X if the defect is first discovered at the release stage.

 

 

A Process for Implementing Shift Left Security

The following four-step process can help you implement shift left security in your organization.

 

Define the Strategy

Create a one-page strategy document that defines your shift left initiative. The document can be rough—you can fine tune it over time as your initiative evolves. It should include:

  • The objectives of shifting left
  • What shift left means in your organization (processes, people, and tools)
  • What will be considered a success with regard to your shift left initiatives?
  • Ownership and responsibilities
  • Metrics and key performance indicators (KPIs)

 

Document Your Current Software Development Process

You must gain a clear understanding of current development and security processes. Many of these processes might not be documented, in which case you will have to conduct interviews with developers and security staff to understand their current practices. Identify the following elements:

  • Which organizational units, teams, and outsourced vendors are involved in building and securing software?
  • Organizational processes and management methodologies (for example, identify whether waterfall or agile methods are used).
  • Infrastructure and environment (local data centers, public cloud, edge systems).
  • CI/CD tools used and their role in the process.
  • The exact process by which code artifacts go from initial development to production.
  • Current security measures and their effectiveness.

 

Implement Security Guardrails

Now that you have established a roadmap of shift left security and the current process is clear, start implementing security controls as part of your quality assurance (QA) process. Every development organization has a QA process; your goal is to add security checks into it. Security issues must be detected, just like QA currently detects bugs, and returned to developers in a rapid feedback loop. It is most effective to provide simple tools developers can use as part of their day-to-day routine to identify and remediate security issues.

 

Train Development Teams in Secure Coding

It is much more effective to train developers to code securely in the first place, than to constantly ask them to address basic security flaws.

Developers are usually not trained in security, and a key component of shift left success is educating them in secure coding best practices. Many developers have low awareness of security and overlook many basic security practices, indicating that training is essential to any shift left program.

 

Related content: Read our guide to DevSecOps best practices

 

Which Technologies Can Help You Shift Security Left?

 

SAST

Static application system testing (SAST) takes a white box testing approach to automated application security. SAST tools scan application source code for known vulnerabilities, providing clear recommendations for how to remediate security issues. SAST can be implemented early in SDLC, because applications do not need to be compiled or run to initiate vulnerability detection.

 

DAST

Dynamic application security testing (DAST) complements SAST using a black box testing approach. It scans compiled, running applications and attempts to inject defects and common attack vectors. This can identify many common vulnerabilities such as SQL injection, cross-site scripting (XSS), and local file inclusion (LFI). It can also highlight runtime configuration issues like authentication, server configuration issues, and flaws in post-login application workflows.

 

IAST

Interactive application security testing (IAST) combines IAST and DAST in a gray box testing approach. It is typically implemented as a proxy in a test runtime environment, such as a Java Virtual Machine (JVM) or .NET Common Language Runtime (CLR). This allows it to monitor runtime operations and simulate attacks within a controlled sandbox.

 

Secrets Detection

The term secrets refers to security certificates, database credentials, API keys, and other similar information that can provide access to sensitive information and systems. Secret detection technology can scan logs, source code, and other files for any hidden secrets that were not removed.

SAST tools and code reviews commonly miss hardcoded secrets, especially during version updates. If these secrets are uploaded to a git repository and become public, systems affected by these secrets can become compromised. Secrets detection technology can prevent this from happening by finding secrets missed by other tools.

 

Software Composition Analysis (SCA)

Software Configuration Analysis (SCA) is an automated process used to identify open-source software and analyze it for security issues, licensing issues, and code quality. Modern open-source components have a large number of dependencies, each of which could contain vulnerabilities.

SCA tools can perform deep inspection of the entire dependency tree to discover components that can threaten the large system. Identifying such components early and switching them for secure components can save a major remediation effort later on.

 

Related content: Read our guide to DevSecOps tools

 

Shift Left Security with Calico

Using policy tiers, Calico enables site reliability engineers (SREs) and developer teams to easily make self-service security policy changes to a cluster without the risk of overriding an existing policy. No central manager or control point is required to create, review, or approve new policies. Deployment of new microservices along with the creation of necessary security policies is fully-automated, adding speed and predictability to the process.

Calico offers the following key features for shift left security:

  • Policy as code – Calico security policies are represented as code that is deployed alongside your microservices, and fully automates the end-to-end deployment process including any necessary security changes. Developers can create policies without having to learn the intricacies of YAML.
  • Policy tiers – Calico policy tiers define the order in which security policies are evaluated (higher tiers evaluate traffic first). Calico automates a validation step that ensures your security policy works properly before being committed, and can then deploy your policy in a “staged” mode that will display which traffic is being allowed or denied before the policy rule is enforced.
  • Policy recommendation – Calico can auto-generate a recommended policy based on ingress and egress traffic between existing services. This can help you implement policy when you are uncertain of the interdependent connections between services.
  • Autonomy – DevOps engineers and service owners can deploy their own set of security policies to applications without the risk of overriding the critical security policies that are required for compliance.
Next steps:

Join our mailing list​

Get updates on blog posts, workshops, certification programs, new releases, and more!