Mar 16 · 6 min read
Your devs have put in the hard work, you’ve committed the first lines of securely written code and you’re ready to build your first artifact. Good work! However, it’s at this point that your precious code lines are often at their most vulnerable. The hand-over of raw code to the build stage comes with new security fallibilities.
The build stage of your CI/CD pipeline is the point where you generally lose visibility of your code, which makes identifying changes to it – difficult. Moreover, compromises at this level are concerning because they are frequently and quickly signed off as legitimate code, making their way into testing and deployment stages – and most horrifyingly – to your Users.
Without getting too technical, an attack on your build environment is an attempt to inject malicious code into your environment with the end-goal of it reaching your users.
Attackers who access your build environment may try to exploit vulnerabilities in this “blacked-out” stage, for example, by:
Learning from recent code manipulation scenarios
Unless you’ve been under a rock, you’ve most likely heard of the I.T. behemoth SolarWinds hack, which is a terrifying example of code manipulation in the build environment of your CI/CD pipeline.
What we know so far:
The New York Times calls the SolarWinds breach a potential “entry point for a huge U.S. hacking.”
“By compromising TeamCity, or exploiting gaps in how customers use the tool, cybersecurity experts say the Russian hackers could have inconspicuously planted back doors in an untold number of JetBrains’ clients.”
At the time of writing, the full investigation is ongoing, so it may be a while till we are entirely in the know of what went down. What’s truly disturbing about the SolarWinds hack is how the attackers played the long-game: learning naming conventions and writing code that looked identical to SolarWinds’ own.
The impact of a single code manipulation depends on the size and nature of the infiltrated product. With SolarWinds, the full damage is being unraveled day by day because of their users’ breadth and authority. Affected parties can break out the consequences into the following categories:
Consequences to your Product:
Consequences to your Company:
Consequences to your Customers & customers’ Customers:
Risks to your pipeline are risks to your customers & their customers. The bottom line is that attackers are continually looking for opportunities to exploit weaknesses – don’t let that happen. Flaws found in your pipeline are potential weaknesses for your customers, leading to your company’s long-term reputational damage.
The first 24 hours is critical to regaining control of ill-acquired systems, files, or servers. Much like when a person is reported missing, the chances of a swift recovery operation hinge on speed, deft decision-making, and a collaborative approach.
Software giant Microsoft, which was also a user of SolarWinds Orion, played an integral part in setting the bar for response and helped to put out the fire. Microsoft’s response to the consequent file manipulation was one of incredible scope, scale, and speed. For an excellent reason – they are Microsoft. They focused on four main defense mechanisms, all executed within three days of the crisis (Dec 13 – 16 2020), to undo the work of the attackers:
These four reactions enabled Microsoft to reassure customers, negate further penetration, and disarm the attackers.
Application security does not mitigate software pipeline vulnerability
You may securely write your code. You may have excellent security processes in your coding stage. Your company may have ‘shifted-left’ your security approach – this is all excellent – for protecting your code.
What about your pipeline? Can you hand-on-heart say your SDLC is covered from risk? Can you halt incoming threats in time to mitigate damages?
In any breach of the build environment, the damage can travel far and wide throughout your supply chain. The end-users having to upgrade their product version doesn’t sound so bad – but the broader harm done is often unknown.
Taking security one step further after a source code manipulation or tinkering in your build environments is advisable. Taking precautions to secure your entire pipeline from code commitment to deployment is now critical.
DevOps is complex – with many moving pieces and tools – each offering their own security protocols. For this reason people who are newer to DevOps might assume that vulnerabilities are minimized or controlled at each stage, however the truth is that protection of your entire software delivery process is the only way to ensure your entire pipeline is secure and healthy.
How Argon Security Solution can help you avoid catastrophe?
We know that attacks at any stage of your pipeline can be stressful and impact your employees, customers, and culture on a deep level. Talk to us about our 3 pipeline security engines, designed to level-up your abilities to keep your integrity and protect your entire DevOps Pipeline.
What is GitLab GitLab is a free open-source service designed to manage and share code in a distributed version control…
The SolarWinds Attack Was the Industry’s Wakeup Call The new wave of software supply chain attacks that targeted SolarWinds, Codecov,…
Hardly a week goes by these days without hearing about a new supply chain attack. A recent headline featured yet…