5 IT Security Considerations for Building a CI/CD Pipeline

How Much “Sec” are you building into DevSecOps?

by Sandhya Sridhar & Dwayne Baptist

In government IT circles, “leading-edge” software developers are adopting DevOps, which is the practice of building bridges between developers and IT “operations” so they can deploy well-tested code into production quickly and frequently, usually with the help of automated, integrated code management and testing platforms. But moving beyond DevOps to DevSecOps – shifting security “to the left” on the development timeline – requires way more effort than simply getting developers and operations staffs together early and automating their mutual needs.

Given the myriad security risks and increasingly sophisticated bad actors around the globe, you can’t pretend to do DevSecOps by simply integrating code scanning tools into your Continuous Integration and Continuous Delivery (CI/CD) pipeline.

Enterprise Cybersecurity teams also need a regular seat at the table with Dev and Ops so they can contribute proactively to a project’s success and not simply be the keepers of standards who say “no”. Automating security requirements and implementing checks-and-balances in the CI/CD pipeline will not replace a formal NIST SP 800-53 process. But collaborating with enterprise IT security with NIST controls in mind will help you catch platform security issues early and will make the formal Authority to Operate (ATO) process simpler and more streamlined.

Most government agencies are not yet using CI/CD to move code all the way into Production. (Aside from a lack of DevOps maturity, there are a number of regulatory and contractual issues that can prevent agencies from doing so.) Many agencies focus on detecting and removing vulnerabilities from code, but they might not have considered whether their CI/CD pipeline itself is secure.

Let’s face it, many organizations relax their security vigilance when operating non-production environments. But that’s a dangerous mindset! Security vulnerabilities in non-Production environments, such as code injection or sensitive data exposure, could lead to severe security issues being promoted into Production. If your agency plans to use a CI/CD pipeline to support Production someday, shouldn’t you start thinking about how to make the pipeline itself a successful, integral, and secure part of your Production environment?

On one CI/CD project Citizant runs for a federal agency, team members have worked for more than a year to accommodate security requirements within DevOps and enhance the CI/CD pipeline by implementing several NIST SP 800-53 controls. Our team met weekly with the agency’s Cybersecurity staff and has already provided sufficient evidence to close out numerous NIST controls. For example, we enabled Jenkins in the CI/CD pipeline to use enterprise single sign-on, using LDAP/Active Directory for authentication. The move to enterprise, role-based security helped address one of the NIST controls. Adopting an enterprise IT security mindset around the CI/CD pipeline will make it easier for this “system of systems” to eventually become an official Production platform.

Here are 5 key security considerations when building your CI/CD pipeline in lower environments:

1)    Review and update your risk assessment.

Did your current overall organizational risk assessment include your non-production environments? If not, then taking a fresh look at risk for the organization will help you clarify what are your needs and priorities. How are you protecting the non-production environments from the outside? Each environment exists for a reason and has different needs and vulnerabilities. Don’t forget to look across departments or sections in the organization to be sure that all needs and issues are accounted.

2)    Train your Agile teams to understand security requirements and correctly interpreting the results.

Just as Agile teams need to understand the operational environment in which their software will run, they need to understand the security requirements. As the DevSecOps CI/CD pipeline produces results, members will have to perform the necessary security activities and analysis required to move forward their application – applying filters, understanding false positives, false negatives etc.

3)    Treat your non-Production environments with the same respect you have for your Production environment.

Wherever you are going to set up your CI/CD pipeline, make sure that you put into place the same security policies and controls. Just as you wouldn’t allow just anybody to touch your production environment, you should be specific about who and how changes are made in the non-production environments.

4)    Treat your CI/CD pipeline as a system.

If you eventually hope to use CI/CD in production, then you need to start thinking about the whole pipeline as a system. A CI/CD pipeline is not simply a collection of tools running automated scripts. So don’t fall for the fallacy that simply buying and configuring a security tool is all you need to do to bring security to your CI/CD pipeline. You need to train your team to interpret results and develop remedial strategies. Be sure to look at the communication and configuration across the entire system to be sure you have addressed all vulnerabilities specific to CI/CD and put in place appropriate controls.

5)    Pay particular attention to how you are automating… and what you aren’t… in your CI/CD pipeline.

Linking pipeline components through automation involves a messaging strategy. Make sure that you have considered your tools, scripts, etc., in the security analysis. Also, consider your practices for any manual intervention (such as certain types of testing), and its effect on pipeline security. Make sure that manual processes are not able to inject malicious content into systems or the pipeline itself, making it vulnerable to future attack.

DevSecOps is a great opportunity to reduce the time it takes to get code into production, and to continuously improve the quality and security of systems. Protecting the CI/CD pipeline, even if it is not being used for Production implementation, is a commonsense idea that will increase organizational confidence in DevSecOps.

About the Authors

Sandhya Sridhar, in her current role as a Security Analyst at Citizant, is responsible for gathering and integrating security requirements into a DevOps CI/CD project and ensures secure functioning of her customer’s business operations. She builds collaborative relationships and rapport with the customer’s Cyber team to understand their requirements, which she packages as concise and complete information for the development team to enhance and secure the CI/CD pipeline.

Dwayne Baptist serves as Citizant’s Director of Strategy. He is a retired U.S. Marine Corps officer, executive, coach, and award-winning speaker, with a broad background in leadership and helping to transform organizations. Dwayne has been advising government officials on creating and delivering value to the public thru information technology for 25 years. He has led teams performing all aspects of IT operations, from software development and network management to strategy and governance.