Why Over-Permissive CI/CD Pipelines are an Unnecessary Evil

Balancing the speed of innovation with security is an age-old problem in software development. This is no different in modern DevOps. Development teams want a frictionless path to deploy new code but often struggle with access permissions that are linked to services. The CI/CD pipeline makes it easier for developers to quickly introduce new features and updates, in an agile way. As application changes move through the CI/CD pipeline, automation can allow changes to happen very quickly, without creating downtime or delays on the customer side.

Permissions of CI/CD Servers

When it comes to the permissions of CI/CD servers, DevOps often don’t want to deny access. After all, the wide access permissions are part of allowing the speed of innovation, and development teams are regularly—and often understandably—cautious about putting least-privilege or other access rules in place.

But there are some security risks to consider. Any developer being granted admin permissions to deploy new code is open to vulnerabilities, weaknesses and misconfigurations. Cloud sprawl has created a lack of visibility into whether or not the infrastructure is properly set up and connected with logging tools. How does the development team know if things are getting properly patched?

The balance is extremely sensitive. DevOps need the speed of change and the ability to innovate freely, but security teams can’t handle the growing risk. Something has to change that can allow security to shift left and get involved earlier in the CI/CD pipelines rather than getting in the way.

Reducing the Risk Without Impacting Innovation

Here are some suggestions for accelerating the speed of innovation while maintaining a healthy security posture:

• Map threats and secure connections. Conduct a threat modeling exercise to map threats to the pipeline. Remember that every connection to the CI/CD pipeline is a potential point of compromise. Regularly patch and scan all services that connect to the pipeline and block the devices if they fail to meet security policy requirements.
• Learn to love logs. When a security issue arises in production, developers, IT engineers and security engineers need to react quickly and efficiently to solve the problem. Logging is critical for enabling fast and coordinated responses. Waiting on manual sharing of sensitive data can slow down reaction times. But when every stakeholder can get the data they need from logs, access to information is no longer the weakest link in the security incident remediation process.
• Tighten access control and enforce strong admin permissions. Be specific about who has access to which data. Clear and enforced separation of duties should ensure no one person or account can access more than necessary in the continuous software delivery pipeline. Improperly credentialed users or bad actors can’t establish control over the entire pipeline and mess with the code or processes. Moreover, they won’t easily be able to penetrate deeper into other corporate systems and data.
• Leverage flags to manage risks. Developers often use feature flags (or feature toggles) to add new features to applications while mitigating the risk that those features will introduce performance or stability issues. Although most developers likely don’t think of feature flags as a security tool, they can be used for that purpose, too. New features are prime vectors for security vulnerabilities, especially if developers haven’t thoroughly tested them yet.

Many security teams do not realize that just because their network is private, they’re still sharing pipelines with third parties, including anyone from maintenance to the team deploying your mobile app. By embracing these tools, developers can shift left, shoring up defenses early in the process, without adding a blocker to the pace of innovation coming from DevOps CI/CD pipelines.