By: Philip Kulp
June 10, 2020
DevSecOps Pipeline: Planning and Awareness
By: Philip Kulp
June 10, 2020
Over the coming weeks, Cybrary will be posting a series of blogs that correspond with the newly released course, DevSecOps Fundamentals. This post is the third in a series covering core principles to assist in the automation of a secure pipeline.
- Securing the Development Cycle [read previous post]
- What Are We Defending? [read previous post]
- Pipeline: Planning and Awareness [current post]
- Pipeline: Development
- Pipeline: Delivery
- Pipeline: Deployment
- Pipeline: Operation & Monitor
- Summarize the learned concepts
Please follow the posts and provide feedback or questions to the author via LinkedIn.
In the previous post, we covered the terminology needed to discuss the protection of modern applications. In this article, we begin on the first step of integrating Security into the DevOps cycle.
Before any security tools or processes are introduced into DevOps, we need to understand the application and the capabilities of the Dev, Ops, and Security teams. We need to:
- Select a structure for our security requirements.
- Select metrics to identify the impact of security on the existing DevOps process.
- Define requirements for the Dev, Security, and Ops members.
- Select security tools based on the app, threats, and existing DevOps process.
NIST Secure Software Development Framework (SSDF)
There are several security frameworks to choose from, such as Payment Card Industry Data Security Standard (PCI-DSS), Open Web Application Security Project (OWASP), Software Assurance Maturity Model (SAMM) and more 2. The NIST SSDF provides a lightweight set of requirements with the practices organized into four groups1:
- Prepare the Organization (PO)
- Protect the Software (PS)
- Produce Well-Secured Software (PW)
- Respond to Vulnerability Reports (RV)
Since the purpose of this series of blog posts is to introduce the fundamentals of DevSecOps and the NIST SSDF aligns with the DevOps cycle, it was selected as an acceptable method for organizing this primer. We are in the planning phase of DevSecOps and can follow the first four practices from the Prepare the Organization family of the SSDF.
SSDF: Define the Security Requirement (PO.1)
The Security team will have to answer a few questions to understand how to integrate into the DevOps cycle. What security requirements will your organization be following? Do policies exist to cover the entire software lifecycle? How will we maintain the policies and procedures? After addressing these questions, the Security team needs to address the roles and responsibilities.
SSDF: Implement Roles and Responsibilities (PO.2)
The organization must prepare for a shift, and the change must be implemented at the highest levels of the organization since adaptation will cut across all divisions. The Security team will need to include assessors with some experience in the Development and Operations so they can attend meetings, understand the terminology, and communicate with external teams. Security needs to have a plan to implement the requirements and be able to define how secure software will improve the organization. This requires roles in the Development, Security, Operations, management, product owners, and any other decision-making roles. A policy-driven approach based on the established requirements will improve the security posture of the developed code.
SSDF: Implement a Supporting Toolchain (PO.3)
The Security team will need to select software that integrates into the DevOps cycle at multiple points during the process: Development, Build, Test, Deploy, Operate, and Monitor. Each tool must produce evidence and artifacts which meet the security requirements. The tools should also integrate into the existing DevOps pipeline. For example, if the organization is using Jenkins for the orchestration, the security tools must produce output that can be processed by a plugin.
SSDF: Define Criteria for Software Security Checks (PO.4)
Finally, the checks from the selected tools must help produce software that meets the defined security criteria. The output from the tools which are imported into the orchestration pipeline should be in a format that can be used for determining pass/fail criteria for each stage. For example, the organization may define a maximum number or level of vulnerabilities produced by the Static Application Security Test (SAST); if the level of findings is exceeded, then the build will fail. Finally, the organization must define metrics to measure the security tools and processes impact on the existing DevOps cycle.
The Dev and Ops teams will have their metrics for measuring quality and productivity, but Security needs their metrics. The metrics will quantify the risk of vulnerabilities introduced into the code, measure the time it takes to fix vulnerable code, and track the impact on the existing DevOps pipeline. Tools should be integrated one at a time so that the impacts can be measured. If all tools are integrated throughout the DevOps pipeline, then bottlenecks or other negative impacts may be difficult to identify. A delta between the pre and post-implementation of a security tool will allow the organization to assess the impact and weigh the results against the reduction of risk.
Security-specific metrics could be established to identify the number of vulnerabilities introduced into the code and at which points. For example, SQL injection or Cross-site Scripting (XSS) vulnerabilities may be introduced in the development phase. After the code is built and deployed to testing, Dynamic Application Security Test (DAST) tools may identify new vulnerabilities introduced by third-party libraries. The test phase may also identify vulnerabilities in the containers or images which run the code. Identifying the phases where vulnerabilities are introduced and tracking the numbers over time will provide the organization with information on where to focus resources.
Security metrics could be established to identify the number of vulnerabilities introduced and the time to resolve the issues 3, 4. Time-to-triage establishes the time to identify the vulnerability and determine the severity. Time-to-investigate follows the triage and creates a schedule to fix based on the severity. Time-to-remediate follows the investigation and determines how long it takes the teams to resolve a vulnerability. Mean-time to recovery can also be used to identify the time to recover from a failure in production.
DevSecOps Team Members
Implementing DevSecOps requires stakeholders from each division in the organization, and each member must understand each other’s role. Developers should have some exposure to basic security concepts. A contract could stipulate that at least one member of the Development team has a secure coding certification. The Security team should also prepare the Development team by explaining the tools used in the pipeline. The use of Integrated Development Environment (IDE) plugins could also provide instant feedback during the coding writing. “Pushing security to the left” means allowing the Developers to make security-based decisions and fixing issues at the cheapest point in the process.
The Security team should consist of members with knowledge of the terminology and practices for the Development and Operations teams. Security will be attending combined meetings, so the representative must be able to comprehend the topics and ask relevant questions to identify issues early. Security team members could also be required to obtain secure coding or other certifications such as cloud DevOps. Understanding the real world processes will allow the Security team to suggest obtainable goals.
Finally, the Ops team should understand the core security concept and requirements. This core knowledge can include secure configuration baselines and best practices, especially if the application is deployed to a cloud environment. Ops members may be required to obtain security-based certifications or have at least one team member with a management role to verify a secure architecture is maintained.
After the requirements are defined, the application is understood, and all team members have the knowledge for deploying a secure application, the security tools will be selected. The security tools should provide an automated method of execution and report generation with a structured format to ingest, such as XML or JSON. Preference will be given to tools that have a plugin to the existing DevOps pipeline software. The tools should have an Automated Programming Interface (API) or another method of trigger based on events in the pipeline.
As mentioned earlier, tools that integrate into the Developer’s pipeline, such as IDE plugins will provide information early instead of relying on the Security team’s review and reporting. The SAST tool must support all of the coding language used in the application. The DAST tool must be able to support the type of application to be tested. For example, some webapp scanning tools are better at crawling a website and discovering endpoints to scan, but may not perform well against an API. In a later blog post, we will discuss Integrated Application Security Test (IAST) tools, which are embedded into the application server. We will provide telemetry data to a rules and analysis engine to identify security flaws. An environment that relies on Infrastructure as Code (IaC) would need a tool that supports the evaluation of a secure baseline or a method of providing Compliance as Code (Cac).
Cybrary offers courses that cut across the entire DevSecOps topic. You can take classes on secure programming, hacker fundamentals, system administration, cloud certifications, and much more. The knowledge will be fundamental to implementing a secure application across the lifecycle of DevSecOps. Signup for Cybrary to learn more about the topic and stay informed of the continuous release of cybersecurity training at Cybrary.
About the author
Dr. Philip Kulp is a Cybrary Fellow and instructor of several courses on the platform. In his current role as a cybersecurity architect and incident responder, he combines his passion for IT and cybersecurity to develop realistic approaches to secure the enterprise. He performs the roles of an independent assessor, incident responder, and secure code reviewer. Philip seeks opportunities to balance his cybersecurity skills between academic, technical, and compliance roles. He holds the CISSP certification and two Offensive Security certifications of OSCP and OSCE. In his educational capacity, Philip serves as a chair, committee member, and mentor for doctoral students in the Ph.D. and D.Sc. programs at Capitol Technology University. Visit his author page on Cybrary or contact him via LinkedIn.
Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF). Retrieved from: https
Secure software development: NIST joins the parade. Retrieved from: https
DoD Enterprise DevSecOps Reference Design v1.0. Retrieved from:
- Security Metrics that Actually Matter in a DevOps World. Retrieved from: