ADAPT AND THRIVE: The Importance of Locking Down Your Software Development Pipeline
The third article in our business series, Adapt and Thrive, covers the importance of solid security and compliance for software delivery pipelines. Speed is key for software companies but not at the risk of security breaches or compromised data.
Compliance, unlike its cousin, cybersecurity, is a contender for the least sexy subject in business. But when it comes to the speed at which you can introduce new software features, getting them both right is critical.
Updates to your apps make their way from developers’ keyboards to live production environments via increasingly complex pipelines – and at every stage of these pipelines, security and compliance issues can arise. But by implementing automated policies, you can stop them before they land you in trouble.
Boardroom Summary
- Software delivery pipelines are vulnerable to compliance and security problems.
- Implementing automated policies (policy as code) can stop this.
- With policies in place, your teams can issue software updates faster.
- The faster you can bring new fixes and features to market, the more effectively you can compete.
- The best model for implementing these policies is called GitOps and Policy as Code.
This is the third installment of a 3-part series. In case you missed our previous posts, here they are.
Part I: ADAPT AND THRIVE: Digital Transformation for Business Success
Part II: ADAPT AND THRIVE: The Right Way To Do Automation
The Need for Speed
In business, everyone wants to deliver at speed. It’s how you compete. And nowhere is this high-velocity delivery more important to competitiveness than in the creation of new software features. Whether they fix bugs, plug security holes, improve the customer experience or streamline back-office operations, software updates and enhancements are critical to success.
But there is something else that is also critical to practically every business: compliance with regulations. Whether you’re in banking, logistics, travel, hospitality, retail or any of thousands of sectors that rely on a strong service element, you need to ensure that every change is compliant with the relevant laws, everywhere you operate. Failure to do so could result in heavy fines. The only reliable way to guarantee this is to bake centralized compliance into your processes from the outset.
Isn't this Just Security all over Again?
Yes and no. Compliance is not the same thing as security, although the two often go hand-in-hand. That’s because much of the legislation you need to comply with necessitates good security practice, especially around data protection. A non-compliant business is therefore likely to exhibit a poor security posture and vice versa.
Some of the differences, it could be argued, are just cultural. The vocabulary of security is becoming increasingly militaristic, while compliance can feel pedestrian in comparison. Compliance is about rules and regulations, after all – not responding to attacks. But the differences between security and compliance run deeper than that. For instance, depending on the size of your organization, you may or may not have a dedicated information security department, who you might expect to take responsibility for all things security-related. But even if you do, the security of something as specialist as your software delivery pipeline is unlikely to fall within their remit – it’s too specialized. That means that security of the software development process, like compliance with the appropriate regulations, cannot be left to another department. It can and should be the responsibility of the people who manage the pipeline itself. This is what we understand by shifting security left.
Security Can make you Compliant
With these pipelines increasingly being used as an attack vector for malicious actors, and the responsibility for their security lying largely with the operations teams responsible for them, it is vital that they are designed with security baked in from the beginning.
The good news is that locking down your pipeline needn’t mean redesigning everything from scratch. There are ways to ensure the entire development pipeline is secure, without the purchase of new tools, without re-architecting entire platforms, and crucially, without the learning curves involved in retraining busy personnel.
One of the best models for this to emerge in recent years is GitOps – a model built on Kubernetes, a container orchestrator which many cloud native platforms are now built on, and Git, a version control system used by developers all over the world. GitOps uses a third application to provide a direct link between Kubernetes, where the code is running, and Git, where it is stored and updated.
By running every change through version control – and by ‘every change’ we mean configuration changes as well as application code – you can radically reduce the opportunity for anyone to make manual, unauthorized changes as well as hold on to an immediate audit trail. And thanks to the continuous monitoring that GitOps brings to your applications, even if someone did sidestep the system and make an unauthorized change, it would be flagged by the system immediately.
Best of all, GitOps can be applied to application delivery retrospectively. As long as you are running on a Kubernetes cluster and your code is in a Git repository, it is easy to bring the whole pipeline – right through to the production application – under GitOps control.
Compliance Guardrails in Action
By tying the information stored in Git more tightly to the state of your live application, GitOps enables you to instantly spot any differences between its ideal state (in Git) and the clusters in production. This holds true whether those changes are the result of a malicious attempt to damage or infiltrate your infrastructure (typical security concerns) or mistakes made by members of your team as they work (more likely a compliance issue).
In either case, prevention is always better than cure. And in a GitOps pipeline, much of that prevention is delivered via policies – automated rules that govern what kinds of changes (whether to code or configuration) can be accepted by the system. Their implementation results in what is known as ‘policy as code’.
All kinds of policies can be added. A policy could ensure good security practice, or making sure your standards of coding and annotation are met every time. But many will be directly related to compliance with the laws and regulations that apply in the territories where you operate. In the US, for example, there are the SOC 2 data protection regulations, in Europe companies need to adhere to GDPR. Organizations that take or manage card payments must comply with the rules set out in PCI-DSS, while those that deal with the health data of US consumers must comply with HIPAA. Policies for all these requirements and more can be baked into GitOps-controlled software delivery pipelines, representing guardrails for everyone on your team.
Sometimes the Problems are Closer to Home
So far, we have talked about compliance and security – as if they are discrete issues. Yet policy as code can help you address the problem that lies at the heart of many a security or compliance SNAFU – human error.
We all make typos. And when you’re configuring a cloud application, one typo can be literally crippling. Policies can ensure that mis-typed configurations are flagged early, as well as the kind of errors that will fall foul of the regulations mentioned above. Of course, human reviewers could do the same job, but with so many files to review in any major deployment, critical errors can still slip through the net.
So whether it’s a typo or a developer attempting to find a shortcut by ‘tweaking’ your application’s configuration, policies will spot it – so you can stop it.
Now there's No Need to Slow Down
Compliance, security, and the kind of coding standards that should prevent erroneous configuration from rearing its head – all of these things sound like they would slow down delivery of new features and fixes. Yet with the right approach to your delivery pipeline, you can automate the detection of anything that could land you in trouble. Which means, ultimately, that your entire team can work faster, free of the responsibility to spot any errors themselves. Our approach to Trusted application delivery adds policy as code to GitOps, enforcing security and compliance, application resilience, and coding standards from source to production.
Contact us for a demo today on Trusted Application Delivery, a single, scalable way to manage policy throughout the application lifecycle and across every pipeline, cluster, and cloud in your organization.
Whitepaper: Trusted Delivery with GitOps and Policy as Code
Trusted Delivery promises organizations exactly that - trust!
