Select Page

Shashank Srivastava

last updated on August 29, 2023

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,


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.


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. 


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. 

Best Practices for Implementing DevSecOps

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).

OpsMx Security scan as a pipeline

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. 

Shashank Srivastava

As a Country Manager, Sales & Marketing (ROW) at OpsMx, Shashank is responsible for revenue for Europe, Middle East and Asia Pacific. He is also responsible for Product Marketing and Strategic Partnerships. Shashank brings in over 20 years of experience in selling and marketing technology / software solutions. Over these years he has led teams for marketing, sales, business development and field operations. He has successfully driven several strategic initiatives within startup environments.



Submit a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.