This blog emphasizes on how to ensure secure software delivery with increased velocity at scale. The absence of velocity (at which business is done) and scalability can still keep business floating but if you pull security (which is a must have) will severely impact business. Keeping security as a focus let me share insights into how to ensure:
- Code Security,
- Image Security,
- Cloud / Infra security,
- Process Security,
- People Security, and
- Collaboration between teams,
- In a proactive way (automation).
No better way than executing or implementing DevSecOps with help of a tool that brings out-of-the-box capabilities to support Security Best Practices and at the same time addresses real-world security challenges for achieving secure software delivery.
Based on the 3 pillars of SecOps – Prevent, Resolve, and Secure, here’s a quick insight into the capabilities that will help identify and eventually choose the right DevSecOps tool for your enterprise.
Just to get the understanding right,
Prevent
This focuses around preventing vulnerabilities and security issues throughout the software delivery process. This involves and is not limited to security scanning, integrity checks, secured pipelines and policy enforcements. The DevSecOp tool must support the automation of these security checks at various stages to prevent vulnerable software from being promoted to higher environments. The checks must be simple and easy to implement in devops process in adherence to the enterprise policies.
Resolve
This focuses around discovering and resolving vulnerabilities, in existing and new releases. Tool must support identifying vulnerabilities close to the problems introduction and provide feedback to resolve before proceeding to higher environments (shift left). It involves capabilities to deduplicate issues found across multiple scans, provide risk guidance on the issues to support prioritization and quick resolution of vulnerabilities.
Secure
This is about demonstrating the security capabilities of the software delivery process and includes, visibility into risk/compliance posture of the delivery of the application and provide provenance information including deployment bill of materials (DBOM), end-to-end traceability, vulnerability and exception management – all to identify common risk patterns and address them effectively.
Let’s look into the capabilities required for shortlisting and selecting a DevSecOps tool specific to your requirements.Importantly how do you apply these security controls without undue burden on an already overburdened enterprise (including the resources), while leveraging the existing investments.
Minimum Required Capabilities
The ability to discover current status / posture with minimal effort (jenkins build, container, CVEs, what’s running where should be the key focus besides the ability to specify policies / best practices at each life cycle stage and provide guidance on compliance. To enable all of this you would require the following minimum required capabilities:
Automate Security Scans
Capability to execute security scans at different stages of the software development or delivery process – code quality check, vulnerability scan, infra scan, etc. While you might be using specific tools for point scan the idea is to automate scans, apply policies, get visibility into the status of the results. You would eventually need workflow orchestration capability that would not only trigger scans but also help you derive actionable intelligence to automate the next steps post scanning results.
Derive Actionable Intelligence from Scanning Results
Ability to interpret the output and apply intelligence to help make an informed decision. Ideally, the tool should be able to offer automated actions based on the result (at minimum – kill the process, approve and go to the next stage, etc.).
Auditable Reports from the Security Scans
There should be a way to generate report/s on specific scans, applications that offer insights into the performance of the software delivery process from a security perspective.
Deduplicate Results
The tool should be able to clear the noise by deduplicating the results to avoid a barrage of alerts and notifications for the same vulnerability. Capability includes Identification of issues found across multiple scans, provide risk guidance on the issues to support prioritization and quick resolution of vulnerabilities.
Correlate Results
This should allow you to correlate multiple breaches or offences at any given point in time. For example A single vulnerability may trigger multiple breaches and hence the correlation helps in fixing multiple issues by pinpointing a specific root cause.
Dashboard for Visual Illustrations, Analysis and Reports
While the tool may do its magic behind the curtains, there should be a mechanism for teams to monitor what’s happening.
Advanced Capabilities
Analyze Results
This capability deciphers the outcome of scanning results from specific tools and allows the user to make informed decisions (whether the scanning has passed or failed). This may be simple to achieve however as advanced capabilities the tool should be able to automate such decisions as well (move to the next job in the workflow if the scanning passes or terminate the workflow if the scanning fails and send notifications to relevant stakeholders).
Security Scan as a Pipeline / Job
As a separate pipeline
This capability comes handy in complex scenarios. For example, let’s consider your application consists of services that are coded by different teams. Let’s say these are different WAR files and the end application is a result of packaging these WAR files. In such a scenario what would make sense is to have separate scanning activities for each code / package in the form of an individual pipeline. Once these individual WAR files are scanned the tool should trigger a subsequent pipeline to assemble the package or trigger a build job. This capability ensures that you continue to shift-left in terms of security and adhere with the principles of Continuous Integration (CI).
As a job within CI pipeline
The ability to have a scanning stage as a part of the pipeline fosters scalability and reliability with increase in the volume of release process. To have code quality checks and code analysis as a job within a CI pipeline helps create a repeatable factory-model in software delivery.
As a job within CD pipeline
The scanning job within a CD pipeline may refer to pre deployment checks (for example, around infra and CVE or the production environment post deployment or the provenance check).
Scan Result Governance
Create tickets
Ability to derive actionable intelligence and up the game for any enterprise. This can be leveraged to have jira driven or governance controls for audit purposes. For example, upon scanning failure or pass the Jira ticket can be created for workflow and future references. This would also pave the path for compliance automation.
Update tickets
Similarly, the Jira ticket can be updated for issues
Prioritize vulnerabilities
This capability allows you to prioritize vulnerabilities. For example, not every vulnerability is going to be a showstopper (PO). Some of these would be P1 and P2 or may not reach the user level. Those vulnerabilities that don’t affect the user can be assigned a low priority. Another way is that the deduplication of issues can help provide compliance guidance and lead to prioritization.
Policy Orchestration for Compliance and Security Automation
As discussed above, orchestrating policy provides guidance to compliances that the point scanning tools may miss. The key capabilities for achieving this includes:
UI to Create and Manage Policies
Ease of use for users to define and orchestrate policies for and at different stages of the process.
Support Policy as Code
Tool should be able to allow users to manage policies in the form of reusable templates. The users should have the ability to create a new policy or re-use an existing policy (from the library) while version controlling it for audit purposes.
Enforce Policy as Guardrails
While policies are orchestrated to provide guidance on compliances, they can also be used to provide additional guardrails. The policy violation leads to termination of the workflow resulting in high security.
For CI
For example: a policy to ensure that no process should skip the code scanning stage.
For CD
For example, no software release or deployment should happen without reviewing the code scanning results.
For DevOps Toolchain besides CI/CD (Governance, Collaboration, ect.)
For example, the software should be deployed to QA for testing purposes irrespective of open vulnerabilities but it shouldn’t be released or deployed to QA if there are any high priority open tickets on Jira or Service now.
Another example is, if the performance score of the application is average then the results should be presented to the stakeholder (QA manager) for manual review irrespective of an automated decision. A policy can be set for this.
For Compliances (SOX, etc.)
For example, a policy can be orchestrated for ensuring that the user checking in the code should not be the one approving the deployment. The approval should happen from a manager or an admin. This would also require Role Based Access Control (RBAC) to ensure additional guardrails, which is covered under enterprise features.
Enterprise Capabilities
These are the features that any large or medium enterprise would probably care about in case they intend to have a centralized tool yet enable a decentralized management and control of the workflow for individual teams while keeping the activities totally agnostic of the tools these teams are using.
Single Sign On
This is a no brainer. The tool should be able to leverage the mechanism an enterprise follows. There are several SSO mechanisms, including but not limited to signing with Git users as an example.
Role Based Access Control
This results in additional security around access while setting up guardrails for approvals and authorizations besides creating a framework for compliance and audit. With RBAC enterprises can set up access controls for specific tools, specific tasks within workflow, tighten security and have better governance based on the roles and privileges for specific groups of users.
Audit Reports and Dashboards
Knowing who did what and when is extremely important. The audit capabilities of the tool should provide exact information (over a period of time) with the press of a button. There are specific audit reports for:
Application Audit
Information about the status of the application and its deployment history.
Vulnerability Audits
Information about specific vulnerabilities and their occurrence and status over the period of time
Policy Audits
Information about specific policy execution / violation for different applications over a period of time.
Vulnerability Exception Management
Information about certain vulnerabilities categorized as “not vulnerable” with specific reasons, over a period of time.
In my next post I will talk about what a modern day DevSecOps should look like. Open for feedback and happy to answer any questions.
0 Comments