At an event we repeatedly heard from the visitors that the delivery teams are notified of the vulnerabilities just before the production deployment or after the deployment has happened, which is too late. There was a lot of focus on shifting-left security to detect, prioritize and remediate security vulnerabilities early in the application development lifecycle.
This shift not only ensures that the right security measures are taken through the SDLC process but also ensures that security and addressing issues becomes less expensive.
In this blog, I will focus on understanding shift-left and how security controls are integrated in your process, besides best practices to incorporate during the implementation with necessary tools.
Understanding Shift-left
The shift-left approach allows quality and security checks early in the SDLC process to detect, prioritize and remediate issues earlier than later. This is implemented by integrating security testing tasks with specific stages of your CI/CD pipelines.
This reduces the cost of fixing issues, improves application security posture while ensuring fast and reliable releases.
The drivers of Security Shift-left
Attack Surface is Shifting Left
Traditionally security is more focused towards infra and network. But as hackers are becoming sophisticated the attack surface has started shifting left at code, build, third party libraries as well as artifact stages. It is relevant for the security teams to start focussing on these stages of software development and detect issues early by incorporating shift-left approach in their strategy.
Secure Code Development
While this is the fundamental objective of AppSec it brings significant advantages in terms of early detection and cost savings. This requires code security review and static code analysis early in order to fix and deliver secure software faster.
Detect, Prioritize, and Remediate Vulnerabilities
As a part of vulnerability management, it is very important to categorize vulnerabilities and their source stages – code, build, artifact or production. It brings significant value if a security engineer is able to categorize and prioritize vulnerabilities in order to have early detection and remediation. This also helps you to navigate through hundreds and thousands of alerts you might be receiving today and focus only on those that matter the most.
Application Security Posture Management
The purpose of shift-left and integrating security with your CI/CD pipelines also provides unified insights into security posture of your applications as code progresses to different stages – code, build, artifact, deploy. This helps the security team compare the security of an application or a service across multiple releases and across different environments (Dev, Staging, and Production).
A unified view is significantly important in cases where there are multiple distributed teams responsible to develop and deliver specific services as part of overall application development. To ensure security and compliance controls, global visibility of the security posture irrespective of the tools used is extremely important.
Reduce Cost of Security and Vulnerability Management
Fixing a defect early is significantly less expensive than the one identified in the production stage. This is achieved by the shift-left approach. Besides this, the majority of enterprises use a combination of open source as well as paid enterprise tools for security scanning and testing, which usually have a lot of overlapping features and functionalities. These tools can be consolidated into a mix of paid / open source and can come as a part of the ASPM tool that provides unified analysis and optimize the license cost of the paid tools.
OpsMx Delivery Shield comes bundled with open source security scanning options to make it easy for early or a mid stage organization to get started with the shift-left implementation. Large enterprises who have already invested in specific tools can continue to leverage their investments or optimize cost by opting for the capabilities coming along with OpsMx.
Below illustration explains what is currently bundled, however we are not restricted to these capabilities. To get clarity please reach out to your OpsMx rep or contact us to get insights into our product roadmap for upcoming capabilities.
Best Practices in Shift-left
Security and Compliance Frameworks
It is important to follow and conform to specific standard security or compliance frameworks based on your business operations (business compliance, industry regulations, data privacy, etc.). To conform, you must have access to specific rules or policies that act as a complete checklist from a compliance perspective. For example: NIST, OWASP, FedRAMP, HIPAA, SOC, etc.
OpsMx Delivery Shield has a built-in library of policies to support these commonly referred frameworks.
You may want to refer to this white paper; Using Your Software Delivery Process to Achieve NIST 800-53 Compliance.
Integrate Security into you CI/CD workflow
Security checks include a number of security testing practices including Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Software Composition Analysis (SCA), Secrets scanning, Build scanning, Production scanning, and vulnerability scanning etc.
These are done by specific tools and services, some of which may come as a part of your cloud services and others are done by specialty tools such as Semgrep, Sonar, Trivy, or other paid tools. As a best practice the purpose of Integrating these tools and specific security checks is to prioritize and remediate security issues on the basis of risk severity.
The purpose of integrating these security checks is to ensure automated scans upon an activity within your software delivery process while making it a consistent and repeatable model.
For Example: Trigger a code scan once the code is committed. Detect and prioritize the risks by providing recommendations to the engineer. Do not proceed to the build stage if critical or high risks vulnerabilities are identified in the scan. And, bridge in the developer-security knowledge gap by offering recommendations (on how to fix the issue) coming out of the analysis.
Automate Security Controls
Once the scans are automated, the next step is to automate data driven decisions by enforcing policies. As a best practice the security analysis and decision making needs to be consistent and efficient in terms of time.
An enterprise receives thousands of alerts and it is impossible for a human to analyze and determine the prioritization of fixes on the vulnerabilities identified. And, not to mention that there’s not just one scanning stage in your pipelines. The scanning may happen at the point of code check-in, after the build has been created, at artefact stage or before and after production deployment.
The idea of enforcing policies is to take data from your DevOps and Security tools, ingest that data to the policy orchestration and automate a decision based on that data.
For example: Block a build if the code scanning has identified critical vulnerabilities. OR, Allow build creation but notify the engineering manager if low risk vulnerabilities have been identified. Another example is, block a deployment if there are high or critical vulnerabilities identified.
Unified Visibility & Real-time Insights
While it is important to have real-time visibility, it’s equally important to have a global view of your application security posture so that you are able to detect and determine the stage where security posture of your application is getting degraded.
Ability to compare how your applications or services are doing over different releases or different environments is significantly important as well.
Reporting and notifying stakeholders in real-time, while enforcing a decision out of the security test analysis is critical.
Audit Readiness
Reporting and the supporting data is a fundamental step towards audit readiness at any given point in time. The shift-left approach and the facilitating tool should provide a mechanism to generate audit reports to confirm that the compliance check-list is met.
Secured Deployments
As a best practice a high risk or a vulnerable code shouldn’t get deployed in the production environment. But, this doesn’t necessarily happen every time, unless you have a mechanism to block deployments upon identification of risks or security vulnerabilities. This should be combined with a mechanism to run automated security checks on infrastructure as well as automated periodic checks for zero day vulnerabilities. Idea is to get insights into which services are getting affected from a vulnerability and where they are actually present in the production environment.
Summary
OpsMx Delivery Shield has been created to fit in any enterprise software security requirements with ability to co-exist with their existing tools (DevOps or Security). There are 100+ out of the box integrations available to seamlessly connect with your code repository, governance, CI, CD, observability, collaboration, notification, log monitoring tools, etc. To optimize overall costs of tools and for medium / small enterprises, Delivery Shield brings in security testing and scanning capabilities bundled in the product just in case these tools / capabilities are not available within an enterprise or in case they want to consolidate their paid license costs.
This space is significantly evolving and so is the tool vendor landscape. To learn how OpsMx can help you stay ahead of the curve, please feel free to request for a Delivery Shield demo or talk to one of the top security experts.
0 Comments