Introduction to the DevSecOps Guideline: Rules for Secure Development at the Process Level

The number of cyber incidents is constantly increasing, which forces companies to respond to growing risks and makes DevSecOps practices mandatory in the development of IT products. At the same time, the clumsy implementation of measures not only does not guarantee the safety of development, but can cause the opposite effect. Let's figure out what and when you need to do to make development safe. The material is based on the webinar "DevSecOps: Organizing Secure Development at the Process Level".

DevOps vs DevSecOps

DevOps is a software development methodology that combines Development and Operations to build a more efficient and faster process for developing and delivering applications. The main goal of DevOps is to establish continuous communication between developers, testers, and administrators to make the product lifecycle seamless. DevSecOps can be considered as an update to the DevOps methodology: the approach does not imply the expansion of the classic DevOps pipeline, but only the integration of security methods into it. At the same time, according to DevSecOps, information security specialists are involved in the development cycle, who ensure that:

• the implemented solutions do not contradict the information security requirements and regulations of the company;
• There are no vulnerabilities in the configuration.
• all system components have up-to-date patches and are correctly configured;
• operational documentation was developed in the context of information security.

According to DevSecOps practices, you need to start thinking about development security at the planning stage of the future product. Otherwise, a situation may arise when, for example, the code is written perfectly, but in the technical design it is possible for users to assign themselves privileged rights, which completely eliminates any further security measures.

Differences Between DevOps and DevSecOps LifecyclesFollowing the DevSecOps methodology provides developers and businesses with a number of benefits.

• Improve application security. DevSecOps practices state that security must be ensured and enforced at every stage of the product lifecycle. As a result, the project receives in-depth protection from any possible threats to information security.
• Reduction of Time-to-market. Usually, the product is checked for compliance with information security closer to the release. Accordingly, when any problems are detected, developers are forced to roll back to the stage with vulnerabilities, fix them and re-check the project. This is not only difficult and expensive, but also time-consuming, which affects the timing of the product release. With DevSecOps, most bugs can be caught the moment they occur, which reduces the time to fix bugs and shortens the time-to-market.
• Improving the quality of products. The concept of DevSecOps implies a deep study of all the details of the project: scenarios of user actions, necessary functions, options for responding to vulnerabilities, and more. This makes the design and development of the product a bit more complicated, but allows you to create a solution that is more satisfying to the needs of users.
• Implementation of a safety culture. Previously, developers were focused on the quick release of projects or the prompt closure of tasks in their area of responsibility. As a rule, security concerns were left to testers and information security specialists. With the introduction of DevSecOps, there is collective and personal responsibility: any mistake made will immediately return for revision.
• Building communication and unification of approaches. Close collaboration between developers, testers, administrators, and security specialists means that the tools and methods used are unified. This helps to get away from the "zoo of technology" and simplifies onboarding.

DevSecOps Guideline

There are several approaches and best practices that define the norms for embedding DevSecOps principles in the development process. One of the basic tomes in this context is the OWASP DevSecOps Guideline , a community-driven guide that explains how to properly build a secure development process and identify any issues early. The main purpose of the rules described in the DevSecOps Guideline is to ensure the security of:

• Custom Code Security
• Supply Chain Security,
• Runtime Protection.

At the same time, each stage needs its own measures and approaches. There are seven stages:

• Init (initialization stage),
• Pre-commit,
• Commit-CI,
• Сontinuous-Delivery-CD,
• Deploy-CD-Colive,
• Operation,
• Governance.

Let's take a closer look at each of them.

Init Stage

Initialization is a stage where there is no code yet, but only the idea of the future product. According to the DevSecOps Guideline, at this stage, it is important to:

• Instill a culture of secure development within teams.
• Identify a Security Champion within each of the teams, i.e. members of the development team who act in the interests of the information security group.

At the same time, it is important to understand the following:

• A culture of secure development should not be imposed and imposed. If a specialist does not understand the value of innovations, any initiative can be pushed into the back of the drawer and sabotaged. Optimally, the transition to DevSecOps should be evolutionary, not revolutionary. It is also important that the idea of safety culture permeates all structures of the company, and that the management initiates its implementation.
• Usually, a specialist from the team is assigned to the role of Security Champion. But it is important that the person in this role is independent and unbiased, for example, that he does not keep silent about possible risks under pressure from his superiors. Therefore, the Security Champion is often a team leader, and sometimes even specialists from the information security department, testers, or auditors. It is also important to have more than one Security Champion in the team: this increases the Bus Factor and dependence on one specialist, which is better to avoid.

Pre-commit stage

The main task in the Pre-commit phase is to check security at the stage when the code has been written but has not yet made it into version control. The DevSecOps Guideline dictates that this requires comprehensive measures.

• Develop threat models. You need to determine how the application will work, in what contours, with what access rights, and with the principles of interaction with other components. It is important to identify all potential risks, provide protection against them, and develop an algorithm of actions in case they occur.
• Check your code for secrets. It is important that the repository does not contain secret data along with the source code: passwords, access tokens, identification data, a description of the implementation features, and others. Checking for secrets can be done either manually or with the help of tools. Better in combination.
• Secure repository configuration. A repository should be a real safe. To do this, you should filter files for write, restrict access rights (including writes) to the repository based on the principle of least privilege, monitor and commit all requests to the repository.
• Use of linters. Working with linters is the ability to statically check the code for suspicious elements, complex syntax, structural errors, style violations, "unusual" patterns of function declarations, and other problems. With their help, you can find and close holes in the code that can be exploited by attackers at an early stage.

Commit Stage

A commit is the stage when the code is rolled out to the public and made available to other users (even if the repository is closed and only a limited number of people have access to the code). In fact, at this stage, the code "glows" outward for the first time and can become a target of attackers, so the measures at the commit stage must be appropriate. It is important here:

• Perform static code analysis (SAST). The method helps to find errors in the code that can lead to security problems without the need to launch the application. SAST works on the principle of a linter, but with different functionality. The use of this method reduces the likelihood of vulnerabilities getting into production.
• Perform Vulnerability Analysis (SCA). It involves searching for vulnerabilities in third-party components used in the application.
• Configure container images safely. Modern approaches to security imply the construction of a defense-in-depth with independent means at each level. Secure image configuration is one of the layers of application security. It is optimal to use Distro less images, which consist of the minimum number of executable files and libraries required for launch. Distro less images do not have full packages with all the files present in a normal system, which reduces the attack surface and the number of potential entry points for attackers. Moreover, if the image is without a body kit, even in the event of a hack, it will be difficult for an attacker to figure out how to work with it.
• Scan IaC artifacts. In IaC, it is the code that defines the parameters of the infrastructure, its security, integrity, and reliability. To eliminate all risks, you should scan IaC artifacts (such as Terraform scripts) for unauthorized privileged escalations, configuration drifting, errors and incorrect syntax, non-compliance, and other issues.
• Perform Interactive Analysis (IAST). IAST is a hybrid validation engine that combines the benefits of SAST and DAST. IAST allows you to dynamically scan an application using the "gray box" method (the implementation of the application is partially or completely unknown), simulating external attacks through various vulnerabilities.

Continuous Delivery Stage

According to OWASP and community experts, at the Continuous Delivery stage, the main practices for ensuring development security are:

• Dynamic Application Security Testing (DAST) is a test that simulates external attacks on different protection vectors.
• ensuring the security of APIs;
• Check for misconfiguration.

It is worth noting here that ensuring API security in the context of the Continuous Delivery stage, before deployment, is aimed precisely at building a secure API configuration. That is, at this stage, it is necessary to foresee and design:

• connectivity mechanisms;
• systems for verifying access rights, certificates and tokens;
• Isolation of connections, including DMZ, so that even after the API is compromised, an attacker cannot penetrate the internal network.
• Request filtering mechanisms (e.g., by IP)

It is important to carry out such preparation at the Continuous Delivery stage, so that API vulnerability and insecurity problems do not begin to surface at stages when fixing such problems will cost more. In the context of the Misconfiguration assessment, the tasks are reduced to checking configuration files and containers for integrity, debugging, and compliance with risks that "something unnecessary" will get into the deploy — for example, a dirty registry, an outdated container, or even a random file. You shouldn't ignore this stage — you can hope that a successful deployment will confirm the absence of errors, but even a successful launch does not guarantee that problems will not make themselves felt later.

Deploy-CD Stage

From stage to stage, the level of development and the practices used are transformed. Measures for organizing secure development are also being transformed accordingly. Thus, at the deployment stage, the solution of two global arrays of tasks becomes a priority.

• Organize secure storage of keys and certificates. Any leakage of these files and data increases the risk of system hacking and other serious consequences. In order for storage to be secure, it is important to use reliable storage, strictly regulate the procedure for interacting with this data, and delimit access rights to it. It is not a good idea to store keys and certificates together with configuration files in both the private and "public" parts of the network.
• Ensure the security of the application from the point of view of the cloud-native approach. According to the Cloud Native methodology, it's important to ensure security at all levels of the infrastructure, including networking, data storage, containers, and microservices. According to the OWASP DevSecOps Guideline , mandatory security measures at the Deploy-CD stage also include building processes and connecting tools for automatic monitoring, detection of vulnerabilities and attacks, as well as their remediation. At the same time, it's important to use the Cloud Native Application Protection Platform (CNAPP), an end-to-end solution that combines tools to protect server workloads, as well as identify cloud misconfigurations and compliance risks.

Runtime Stage

Even deploying an application and bringing it to the Runtime does not mean that you stop working to create conditions for secure development at the process level. Moreover, at this stage, when there are more potential threats (for example, work with critical and user data begins), the number of necessary measures also increases. According to the DevSecOps Guideline, by the time the application is launched, you must:

• Implement infrastructure vulnerability analysis practices (cloud infrastructure analysis, container analysis in the Runtime) and provide procedures in case anomalies are detected (e.g., replace containers, quarantine them, or delete them altogether).
• implement penetration testing processes (Black box, Grey box, White box), including with the involvement of external teams and the use of automated tools;
• Conduct Breach and Attack Simulation testing – an approach that allows you to continuously simulate cyberattacks to verify cybersecurity without affecting production systems;
• connect to BugBounty — the program makes it possible to involve third-party specialists in product testing and vulnerability search and, as a result, receive prompt feedback and reduce the response time to possible security issues. But you should connect to BugBounty only if you are completely confident in the security of the application — otherwise, the risks of participating in the program will be greater than the profit;
• Configure logging and monitoring processes.

It should be understood that building such a layered defense, which is needed at the Runtime stage, requires a certain level of maturity from the company in terms of security and a significant reserve of resources, both financials and the time of specialists.

Governance Stage

In an ideal world, the application comes to the operational stage with a fully developed, configured and automated (in terms of the use of tools) security system. That is, all the measures and approaches described earlier must be implemented, adopted and work correctly. At the Governance stage, practices that are more related to process management are actually added. For example, according to the DevSecOps Guideline, at the management stage, you should:

• Perform security compliance audits
• implement centralized vulnerability management;
• Use Policy-as-code tools.
• Conduct a Security Maturity Analysis
• Implement Security Benchmarking processes.

In fact, the implementation of these measures closes the security loop and makes the entire development path understandable and transparent, and the product resilient to potential threats.

Inference

Creating the conditions for the development of secure applications is a continuous process that does not stop even after being rolled out to production and requires the constant involvement of both developers and other IT specialists. Moreover, the higher the stage of readiness of the product, the more effort must be put into protecting it from internal and external threats, as well as technical failures – measures must be commensurate with the increase in risks. At the same time, the main condition that determines the success of all efforts is the understanding of the importance of secure development at all levels, from the manager to the specialists in the field. Without implementing a culture of secure development, no amount of cost or effort will yield the expected results.

Continuous Integration (CI) and Continuous Deployment/Delivery (CD) are key practices in modern software development that aim to enhance collaboration, streamline development workflows, and deliver high-quality software efficiently.

?? Definitions:

?? Continuous Integration (CI) is a development practice where developers integrate code changes into a shared repository frequently. Each integration triggers automated builds and tests, allowing teams to detect and address integration issues early.

?? Continuous Deployment (CD): Involves automatically deploying every code change that passes the CI pipeline to production, making new features and updates available to users immediately.

?? Continuous Delivery (CD): Similar to continuous deployment but stops short of automatic production deployment. The code is ready for deployment at any time but requires manual approval.

?? CI/CD Pipeline:

A CI/CD pipeline represents the end-to-end process, from code changes to deployment. It typically includes stages like Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor.

?? Benefits:

- Quick Feedback: Immediate detection and correction of code issues for faster development.

- Consistency: Automated processes ensure consistent builds and deployments.

- Speed to Market: Accelerates the delivery of new features and updates.

- Error Reduction: Automation minimizes manual errors in testing and deployment.

- Team Collaboration: Standardized workflows enhance collaboration across teams.

?? Best Practices:

- Automated Testing: Implement comprehensive automated testing for reliable code validation.

- Version Control: Utilize version control systems like Git for code management and collaboration.

- Continuous Integration: Regularly merge code changes into a shared repository to detect integration issues early.

- Incremental Deployments: Roll out updates incrementally to minimize potential impact and identify issues faster.

- Monitoring and Logging: Integrate robust monitoring and logging to detect and address issues in real-time.