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.
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.
The following four-step process can help you implement shift left security in your organization.
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:
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:
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.
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
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.
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.
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.
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 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
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: