.png?h=100&w=600)
The AI Security Starter Pack
Get 7 of the most widely used AI security resources in one pack. Each asset provides practical tools for securing AI apps, models, and agents.
Automation, DevSecOps & Continuous Security - Security by Design
Products designed with Secure by Design principles prioritize the security of customers as a core business requirement, rather than merely treating it as a technical feature. By designing security into everything we do from the very beginning, we give ourselves the best chance of avoiding attacks – or at least mitigating them when they do happen.
This is where the concept of DevSecOps came from – “an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle”. Historically the security aspects of a system have been something that was retro-fitted just before go-live, but with DevSecOps we deliberately bring the operations team into the construction of a system from day one. This means that the people who are going to operate the system have input to its design, so we stand a chance of making something usable as well as secure. But it also means that the ops team have a level of ownership of the system – which would not be the case if we simply built it, handed it over and said: “Here you go, please operate this”.
There is a slightly ironic problem, though. Look back to the definition we gave a moment ago, particularly the part that says: throughout the entire IT lifecycle. DevSecOps was devised to address the problem of the operational teams not being part of the development of the system. But what about the years after the system goes live?
Security by Design After Deployment
In theory, DevSecOps should cater for this. That is, after all, much of the point of the “ops” component of the term. In reality, though, real life can get in the way of good intentions. There is no such thing as an IT operations team that has time on its hands: there is always something to do and there are always things on the backlog that the ops team have yet to get to.
The priority for IT people is to keep systems running and fix them when something goes wrong. Generally speaking, this takes all of their time. Security risks taking a back seat, not least because while a system failure is entirely binary – one moment something is working and the next it is not – many vulnerabilities and security threats gradually creep in unnoticed over time. Yes, we have some watershed moments, for instance when Patch Tuesday comes around or a zero-day vulnerability hits the headlines, but on the whole, if we look at our systems tomorrow they are not likely to be obviously more at threat than they were yesterday. It is easy, therefore, to take our eye off the security elements of operating IT systems because we are busy keeping them running.
Continuous Security
So how do we deal with this? How do we get to a regime of continuous security?
If the operations team are struggling to find the time to focus on security, we need someone or something else to help them. This does not mean we as the cybersecurity team should be doing their job for them: our role is to secure and to monitor, not to operate. This is also because we are less likely to have many of the skills that we would need to enable us to operate a wider array of IT systems effectively. Step one, then, is to look to automation.
Automation can be a difficult beast to tame. As cybersecurity specialists we are rightly cautious of automation, because we have had to deal with the impact of too many shadow IT scripts written by people across the organization who know just enough to get them into trouble and not quite enough to develop things securely and correctly. But the joy of automation is that once something has been thoroughly tested and debugged, it keeps working the same way as it always did. An automation has no human failings – it does not overlook a step in a runbook, or get tired and forget to run something.
What if we are worried about automations taking actions that might be damaging to our business? Or, given that it is now 2026, artificial intelligence (AI) models doing the same? We have a simple choice: either get senior management to accept the risk, having weighed it up against the benefits of automation; or do not use software that can change the system. There is enormous value in having systems that just carry out read-only tasks across the IT estate and then report the answers to the human team. We use them all the time – network monitoring packages, vulnerability assessment tools, scanners that scour our servers for unwisely saved credentials. None of these tools makes changes and hence none of them risks breaking something – what they do, though, is ensure regular, comprehensive information is available to the human IT teams with almost zero effort on the part of the latter.
However, none of this is new. We have been using tools for years to monitor security and getting the IT team to fix things when they crop up. The thing is, though, another factor has been in play for years too: the IT team will invariably have a queue of security tasks to address and few organizations do more than scratch the surface and get most of the higher-priority fixes done. We have never done continuous security – we have simply done ongoing patching. As the old adage says: the definition of insanity is doing the same thing over and over and expecting different results. If we are to do continuous security properly, we need to change how we act. Or, more correctly, how our systems act.
Unless an organization can afford to hire more people in the IT and cybersecurity teams (which it probably cannot, or it would have done so already) there is only one way to go: empowering our automation and AI technology to make recommendations, decisions and take actions. The “do not use software that can change the system” option we mentioned a few sentences ago is simply not an option on that basis. It highlights a need to embrace automation for security and we have to get senior management to back us in doing so.
Automation Not Absolute
One survey we found while researching this piece found that 0% of respondents said they had a fully automated security remediation workflow. Zero. Nobody at all. Plenty (77%) said they use automation, so there is not absolute adversity to the concepts of automation or AI – just a desire to have a human being make the actual final-stage decisions. So, we have quite a mountain to climb if we are to get to a world where automation enables us to do continuous security.
The way to go is to take one step at a time and to acknowledge that while we probably do not want to allow automation or AI to take every security-related decision, we absolutely need to have it making a non-zero number of them. Automating security response does not have to be a “big bang” approach – in fact we almost certainly want it not to be, or we risk losing control of what is going on.
We can begin by setting our tools into monitor-only mode, letting them report what actions they would have taken had we allowed them. Then, one by one, flip the switch and allow the tools to take actions. Maybe start by letting the EDR tool kill suspect processes or allow the network monitor to down a user’s port if it sees what seems to be a Command-and-Control process. As with most things in life, the step from doing none of something to doing a small amount is generally the hardest; then the feeling of “well, that wasn’t so bad” kicks in and we are able to show senior management that their fears of unwanted outages were largely unfounded. This said, though, there is a zero chance that there will be no false positives at all, so we need to be honest with management that the occasional oddity might occur – and anyway, it is rare that a tool cannot be switched back to monitor-only mode and adjusted if it we find it a little keen to upset the ship.
Automation and AI are, therefore, critical to continuous security. Given that there are very few organizations whose vulnerability scanners and patch monitors show 0% problems, we must be bold and adopt the tools that enable us to run a security regime that quite simply cannot run with humans involved in every decision.
