Select Page
by

Shashank Srivastava

|
last updated on March 28, 2024
Share

Enterprises are looking at compliance as not just another check box but a strategic pillar for trust and building data privacy. Compliance and security controls are the cornerstone to establish safeguards against data breaches and cyber attacks. According to a recent study made by GlobalScope, American organizations lose an average of $4 million in revenue due to a single security and non-compliance event. 

What is the main goal of DevSecOps?

Enterprises formed DevSecOps – a new team to tackle security threats while releasing software at speed and scale. DevSecOps is an approach to ensuring DevOps Security, which brings a security-approach to application delivery or CI/CD process. 

In this blog, we will address the top DevSecOps checklists (or DevOps Security checklists) that a DevSecOps team needs for safe and efficient software delivery.

Top 7 checklists for DevOps team to secure CI/CD

Organizations today are more susceptible to external and internal cyber threats due to the vast attack surface and a lack of end-to-end governance and risk management. Constant focus on speed of software delivery, along with (traditional) slow and manual security checks, has caused teams to overlook security in the software supply chain. 

Since a modern software delivery process includes numerous CI/CD tools, open-source code, distributed teams, and different cloud platforms, teams must also prioritize CI/CD security and maintain a separate CI/CD security checklist to secure their pipeline.

Here’s the DevSecOps checklist that a team must follow to ensure security:

  1. Vulnerability report
  2. DBOM
  3. SBOM
  4. Deployment risk report 
  5. Policy violation report
  6. Audit report
  7. DevOps KPIs

1. Vulnerability report

The first in the checklist is vulnerability report in pre and post build stage (refer the image below). With the rise of open-source tools and libraries, and containers, applications can be vulnerable. Hence security testing to analyze source code and find security vulnerabilities should be automated. Without proper checks, vulnerabilities can go into production, and applications will be susceptible to attack. Famous security testing is Static/Dynamic Application Security Testing (SAST/DAST) to find source code and binary vulnerabilities.

DevSecOps must attempt to automate the security scanning completely by integrating with CI/CD pipelines. For e.g. creating a stage in Spinnaker pipeline to automate the static analysis in 3rd party tools like SonarQube. But implementation is one part, having an holistic understanding about vulnerabilities and code risk across projects and applications in an organization is an important checklist for DevSecOps team. 

Attack surface of supply chain

The post-build stage is crucial and vulnerable in software delivery. It’s where software artifacts take shape and are a breeding ground for security risks. Vulnerabilities, insecure dependencies, and unauthorized access can all seep in during this phase, putting your applications at risk. Addressing security issues at this stage is imperative to ensure your applications’ integrity and safety before they go live.

For more refer 5 Steps to Fortify Software Delivery Security with Automation

2. Delivery Bill of Materials

The second in the checklist for the DevSecOps team is DBOM. It is becoming popular these days with rapid software delivery. Delivery Bill of Material (DBOM) is a consolidated report about software supply chain and security management in the software delivery process. DBOM includes the data such as security risk reports, quality and performance reports, testing reports, and development & deployment history of the application, tools used to deliver the application, etc. 

The primary reason DevSecOps should maintain a DBOM report in the CI/CD is to increase the transparency of the risk of an application to all the stakeholders at each delivery stage. The stakeholders with whom the DBOM can be shared are DevOps, Security or GRC team or compliance managers, Application engineers, delivery team, or the operation team. A DBOM provides a systemic sharing of risk analysis by tracking the metadata, such as software components, and tying it to other information while taking an application to production.  A DBOM report helps organizations to effectively and efficiently consume the application status report in the software supply chain.  

The DevSecOps team should understand the items which would constitute a DBOM. DBOM contains the foundational code component on which an application is built and its risk status. A DBOM report provides holistic information about an application component and its potential risks at various stages of software delivery- code, build, test, deploy, and production. Although the level of information wrt DBOM can vary from organization based on their requirements, below is a fair estimation of what a DBOM report should contain. 

DBOM report

3. Software Bill of Materials

3rd in the DevSecOps checklist is SBOM. A Software Bill of Materials (SBOM) provides those who produce, purchase, and operate software along with other license information that enhances their understanding of the supply chain, which enables multiple benefits, most notably the potential to track known and newly emerged vulnerabilities and risks.

As per National Telecommunications and Information Administration (NTIA) report, an SBOM is a formal record containing the details and supply chain relationships of various components used in building software. An SBOM can help software supplier produce their software in the following ways:

  • monitoring components for vulnerabilities
  • reducing unplanned, unscheduled work with better visibility into the vulnerabile code
  • reducing code bloat in open source software
  • adequate understanding of dependencies within broader complex projects and facilitating better quality management
  • knowing and complying with the license obligations
  • timely tracking og end-of-life (EOL) of software components
  • a blacklisting of banned components
  • provide an SBOM to a customer or downstream partners

In many organizations DevOps teams use SBOM to enhance software transparency. And advanced organizations such as Google, Apple, Cisco, etc, treat SBOM as a part of their Delivery Bill of Materials (DBOM). Thus the SBOM and DBOM form an essential part of a team’s CI/CD security checklist too.

4. Deployment risk report

Risk report (or code-vulnerability report) of a software is one thing, but the risk of a landscape or environment where the software is deployed is another thing. The performance and behavior of an entire system may change based on a new microservice deployment. 

DevSecOps team must understand and share the risk of a new deployment on multiple dimensions such as performance, quality reliability and security of the production system. There should be adequate mechanisms or systems to measure the risk of all the new deployment into cloud, containers or legacy infrastructure. Since a lot of changes will be deployed into the testing and staging environment, the process of risk assessment should be quite fast. The process of risk assessment of a new application after deployment is also known as verification. 

Coming to production deployments, DevOps team may use various kinds of deployment strategies such as canary and blue-green. These strategies are used to progressively allow real-time traffic to the new system to bring down its impact  (if any) on end-customers. But they often involve a process of verification based on which these decisions of allowing more traffic to the new systems are taken. 

The ideal way to carry out this verification is to download the access logs, API logs, and performance metrics of the newly deployed software and its dependencies and check for issues or exceptions or unexpected behavior. DevOps must develop deployment risk reports and share its SREs and developers, because the report will provide holistic information about the impact of the software on existing systems. 

Read more about AI-based deployment risk reports generation wrt performance, quality , security, and reliability.

5. Policy violation report

There can be numerous rules, regulations and policies to govern the SDLC process. Implementing these policies is a one-time activity, but tracking them and taking actions to adhere to the policies is a daily challenge for the DevOps team. Because failure to comply with the established standards or policies can put an organization at risk of breaches, attacks, and fines from regulatory agencies. 

There can be various software such as GitLab, Spinnaker, Jenkins, Argo, Flux, etc, for automating the software delivery process. Implementing policies and tracking the violation will always be one of the important everyday checklists for DevOps or DevSecOps team. 

Very common example can be Black-out-window policy for developers which can state a time or date range when developers should not deploy anything to production (say during peak business hour). The first thing DevOps should do is to implement policies into CD pipelines or workflows of delivery automation tools. And then track it on a real-time basis in case someone accidentally violates such a policy to take proper roll-back actions. 

DevOps team should get weekly and monthly consolidated reports on policy violations to understand the places where the process can be further improved. 

Read more about policy-driven-pipelines and deployment firewalls.

6. Audit

As software release velocity increases, so does the challenge of keeping track of the various deployments and events in the overall software delivery. Also, security and compliance events require an audit of the CD events but also traceability of the artifacts and data that led to the promotion of releases to production. 

Audit report is one of the important checklists for the DevSecOps team. They should conduct an auditing exercise in regular intervals to ensure their applications adhere to SDLC standards and regulations.

To save time the DevSecOps team should consider an automated system to have various Audit and Attestation dashboard in their fingertips. The audit reports should highlight who, what, and when pipeline execution has happened. There should be a proper mechanism to share the reports, with internal or external auditors, wrt to deployments, environment, and event data collected from workflow tasks or pipeline activities.

An automated auditing process ensures you can respond efficiently to compliance requests, maintaining a secure software delivery pipeline. Below are a few types of audit records and compliance checks and their respective benefits for the DevSecOps team and the organization. 

Continuous auditing benefits comparison

7. DevOps KPIs

Monitoring KPIs are an essential part of a DevOps security checklist. With security becoming a mandate, the core DevOps KPIs cannot be ignored. The quantification of the new transformation will be important for stakeholders to understand if there has been any trade-off on the SDLC process effectiveness after integrating security. Hence DevSecOps team must measure the following KPIs (a.k.a DORA metrics) to observe if there is any change after security is properly implemented into the process.

  1. Deployment frequency 
  2. Lead time
  3. Change failure rate
  4. Time to restore the service

If these security impacts these KPIs at an unacceptable level, then organizations must introspect quickly and fix the process to restore the speed to take products to the market.

About OpsMx

OpsMx is a leading innovator and thought leader in the Secure Continuous Delivery space. Leading technology companies such as Google, Cisco, Western Union, among others rely on OpsMx to ship better software faster.

If you are undergoing a transformation of integrating security into your DevOps process, then talk to our Top Secure CD Experts. Our team includes experts in security, CI/CD, DevOps, DevSecOps and cloud. 

If you are looking to implement a DevSecOps platform to secure your software supply chain and deployments into Kubernetes or public cloud, then you should consider OpsMx Secure CD platform. 

Tags : devsecops

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.

Link

0 Comments

Submit a Comment

Your email address will not be published.

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