What Is Shift Left Security?
Traditional software development approaches implement security testing at the end of the development process. Typically, this stage involves performing various types of testing, such as dynamic application security testing (DAST) and static application security testing (SAST).
These tests determine whether an application is released to production or moved back to remediation by developers. Moving the application back and forth between teams and stages causes delays as security measures are added and tested.
Shifting security left involves incorporating security checks across the entire development cycle. It helps ensure that applications are designed with proper security controls from the beginning, rather than adding security as an afterthought at the end of the development.
Shifting security left helps find and remediate vulnerabilities and weaknesses earlier when it is easier and faster to fix them. It also breaks down silos between development and security and creates a more efficient pipeline that quickly addresses security concerns.
Shifting Left Challenges
When implementing a shift left security strategy, teams often face some of the following challenges:
- Lack of collaboration with information security—shifting security left requires collaboration between the development and security teams. Information security capabilities are vital for combating ongoing, widespread threats.
- Lack of security staff—security analysts typically handle most alerts, even when other teams become involved in security processes. There is a global skills shortage today, so the security team often lacks sufficient personnel. Large organizations typically have a single information security expert for every 100 developers. These security specialists are overworked and often unable to deal with the scale of alerts.
- Late involvement of the security team—developers often fail to engage the information security team on time, waiting until the end of the software development life cycle (SDLC). The later they involve security, the more difficult and costly the security-related changes. If security professionals don’t handle alerts on time, they might miss important incidents and allow security issues to persist in later development stages.
- Lack of security risk awareness—developers are often unfamiliar with common security risks (i.e., the OWASP Top 10) or how to mitigate them. Shifting left requires all teams to familiarize themselves with the major security threats and stay up-to-date with security procedures.
- Alert fatigue—the large volume of alerts generated by security monitoring systems makes it harder for security teams to address issues quickly. Advanced security technologies such as behavioral analytics can help reduce false positives and prioritize real incidents, saving time for the overstretched security staff.
- Slow manual responses—manually responding to security threats, although necessary in some cases, can be too slow for an effective shift-left security strategy. Shifting security left thus requires automated incident response tools such as SOAR and XDR to reduce the burden on incident response teams.
Shifting Security Left in Azure
Several tools and techniques can help shift security left in an Azure-based development environment.
It is important to verify the security of all open source components and dependencies to ensure an application is safe. Open source components often contain security vulnerabilities, which introduce risk when incorporated into the application.
Several tools are easy to implement in Azure Pipelines. For example, WhiteSource Bolt checks for vulnerabilities and license-related risks in open source components. It is a limited, free version of the WhiteSource management solution. Other useful tools for running security checks include Black Duck and Snyk, which offer an Azure DevOps extension that is easy to implement in Azure Pipelines.
Secure Storage of Sensitive Information
Sensitive information must remain hidden and confidential. Restricting access to such information is vital for maintaining a secure development pipeline. Only a select handful of individuals should have the ability to view and manage the restricted data.
Azure Storage services are inherently secure and offer strong encryption for data in transit and at rest. In addition, Azure offers a Key Vault, which allows customers to store their sensitive information in the form of secrets that remain hidden to users but are accessible to Azure Pipelines. Variable groups associated with the secrets in the Key Vault enable the interpretation of values in secrets.
Static Code Analysis
It is possible to install a static code analyzer extension using a code editor like VS Code. Developers can use code analyzers to retrieve instant feedback in their preferred code editor. They define rules for the code analyzer, which then provides recommendations. Examples of static code analysis tools include:
- PsScriptAnalyzer—works with PowerShell
- Roslyn—works for C#
- SonarLint—works with various programming languages
Azure Pipelines can help run certain analysis tasks in a build pipeline. Incorporating these analysis tasks into the pipeline helps detect issues such as a developer using an inappropriate coding style or ignoring alerts from the local code analyzer. This strategy ensures that developers fix code and follow the analyzer’s recommendations before the continuous integration process can continue, preventing issues from persisting further down the pipeline.
Azure Identity and Access Management
Developers can use the Microsoft identity platform to build an application that signs in all Microsoft identities and retrieves tokens. It is based on Azure Active Directory and can use these tokens to call APIs, including Microsoft and developer-built APIs.
Identity and access management features in Azure include:
- Azure RBAC—role-based access control (RBAC) is critical for managing access to cloud resources. Azure RBAC facilitates access management, determining who can access Azure resources, how they can use the resources, and which areas they can access.
- Azure AD B2C—a service providing business-to-customer identity. Customers can establish single sign-on (SSO) access to multiple applications or APIs using their chosen business or social account identities.
- Managed identities—automatically provide identities for services such as Azure Kubernetes Service (AKS). The AKS cluster requires an identity to create resources in Azure, including managed disks and load balancers. An identity may be a service principal or managed identity. AKS can automatically create managed identities, which is simpler than manually managing and renewing service principals. Both types of identities require the same permissions.
In this article, I explained the basics of shift left security and presented tools and processed provided by the Azure cloud that can help your organization shift left:
- Open source management tools—Azure integrates with several white source security tools, including WhiteSource Bolt, Black Duck, and Snyk, which can help secure open source components throughout the SDLC.
- Secure storage of sensitive information—Azure provides the Key Vault service, which can help development teams keep secrets secure during development processes.
- Static code analysis—Azure supports static analysis to identify code quality and security issues early in the development process. This can be done via extensions to the VS Code editor, or by integrating static analysis with Azure Pipelines.
- Azure Identity and Access Management—you can leverage Azure RBAC, Azure AD, and Managed Identities to secure access to all development environments.
I hope this will be useful as you shift your security processes left to improve security and promote a DevSecOps culture in the Azure cloud.