A practical approach
There is a shift happening in how the industry talks about agentic AI security. A year ago the conversation was speculative – what might go wrong, what we might do about it. Now it is specific. The platforms, primitives and patterns for operating agents safely exist as named things you can point at on a slide. The vocabulary is converging across vendors. The reference architectures are documented.
In this blog I explore the themes that mattered most, and what they mean for security teams.
Today, organisations are caught between two opposing forces. On one side is the drive for operational efficiency through digital transformation and AI adoption. On the other is an asymmetric cyber threat landscape.
As adversaries leverage AI to increase the scale and sophistication of attacks overwhelming already stretched cyber teams, defenders must do the same by using AI to strengthen security.
The traditional security model is reactive. When a threat is detected, a human must review, validate and remediate. In the time it takes an analyst to finish their first coffee, an AI-driven adversary can exfiltrate sensitive data.
For organisations that depend on customer trust and regulatory compliance, “responding as fast as we can” is no longer within risk appetite. Humans cannot scale to match the speed of automated code.
AI is becoming central to the future of cyber defence. While much of the industry focuses on automating security operations triage, the true power of AI lies in automating complex, proactive security and compliance functions that previously required thousands of human hours.
As organisations accelerate AI adoption, a familiar pattern is emerging: security teams – often the CISO – are increasingly asked to own or coordinate AI governance. That outcome is not an accident. Security leaders already operate across departmental boundaries, manage data inventories, run cross-functional programs and are trusted by executives and boards to solve hard, systemic problems. AI initiatives are inherently cross-disciplinary, data-centric and integrated into product and vendor ecosystems, so responsibility naturally flows toward teams that already do that work. This operational reality creates an opportunity: security can (and should) move from firefighting to shaping safe adoption practices that preserve value and reduce harm.
In this blog I outline key strategies on how to be successfully in leading AI governance initiatives in your organisation.
We are entering the agentic era – an inflection point defined by AI systems that can reason, plan and take action autonomously. This shift may be among the most consequential technological transformations of our generation, and it carries an equally significant obligation: to ensure these systems are designed, governed and deployed in ways that earn and sustain trust.
I completed a 5-Day AI Agents Intensive Course where we dove deep in Google’s open source Agent Development Toolkit. In this blog, I’ll share key takeaways and practical suggestions so you can navigate this shift and learn to build AI agents of your own.
Scaled Agile Framework (SAFe) provides a way for the entire organisation to work in an agile way, not only software engineers. Security professionals, lawyers, compliance specialists and procurement teams are encouraged to engage in sprints (or ‘iterations’) too. You don’t have to write code to participate in a retrospective.
I recently had an opportunity to apply some of the Agile practices in my latest cyber security projects while going through formal Leading SAFe training at work.
Many ideas are not new, especially if you worked with Scrum previously, but they don’t have to be in order to be effective. The framework serves more as a collection of principles and a menu of techniques that can be used to transform large organisations that have ‘always done things that way’.
Product security is more than running code scanning tools and facilitating pentests. Yet that’s what many security teams focus on. Secure coding is not a standalone discipline, it’s about developing systems that are safe. It starts with organisational culture, embedding the right behaviours and building on existing code quality practices.
In the DevSecOps paradigm, the need for manual testing and review is minimised in favour of speed and agility. Security input should be provided as early as possible, and at every stage of the process. Automation, therefore, becomes key. Responsibility for quality and security as well as decision-making power should also shift to the local teams delivering working software. Appropriate security training must be provided to these teams to reduce the reliance on dedicated security resources.
I created a diagram illustrating a simplified software development lifecycle to show where security-enhancing practices, input and tests are useful. The process should be understood as a continuous cycle but is represented in a straight line for the ease of reading.
There will, of course, be variations in this process – the one used in your organisation might be different. The principles presented here, however, can be applied to any development lifecycle, your specific pipeline and tooling.
I deliberately kept this representation tool and vendor agnostic. For some example tools and techniques at every stage, feel free to check out the DevSecOps tag on this site.
There is a strong correlation between code quality and security: more bugs lead to more security vulnerabilities. Simple coding mistakes can cause serious security problems, like in the case of Apple’s ‘goto fail’ and OpenSSL’s ‘Heartbleed‘, highlighting the need for disciplined engineering and testing culture.
I touched upon embedding security in modern software development practices in my previous blogs on agile security and DevSecOps culture and recommended some tools to help automate managing vulnerabilities in open source libraries, help preventing committing secrets in code and integrating application security testing in the CI/CD pipeline. In this blog I would like to touch upon the connection between code quality and security and explore static code analysis.
An open source tool that is gaining a lot of momentum in this space is Semgrep. It supports multiple languages and integrates well in the CI/CD pipeline. You can run Semgrep out of a Docker container and the test results are conveniently displayed in the command line interface.
The rule set is still relatively limited compared to other established players and it might find fewer issues. You can write your own rules, however, and things are bound to improve as the tool continues to develop with contributions from the community.
A more well-known tool in this space is SonarQube. You can still use a free Community Edition for basic testing but advanced enterprise-level features would require a paid subscription. CI/CD integration is possible, inter plugins (like the one for ESLint) are also available.
SonarQube has a dashboard view which scores your code across reliability, security, maintainability and other metrics.
As with any tool of this type, to get the best use out of it, some initial configuration is required to reduce the number of false positives, so don’t be discouraged by the high number of bugs or “code smells” being discovered initially.
Keeping in mind the fact that no amount of automation can guarantee finding all the vulnerabilities, I found SonarQube’s analysis around Security Hotspots particularly interesting. It also estimates a time required to pay down the tech debt which can serve as a good indicator of maintainability of your codebase.
It is important to remember that static code analysis tools are not a substitute for the testing culture, code reviews, threat modelling and secure software engineering. They can, however, be a useful set of guardrails for engineers and act as an additional layer in your defence in depth strategy. Although these tools are unlikely to catch all the issues, they can certainly help raise awareness among software developers about quality and security improvements, alert about potential vulnerabilities before they become a problem and prevent the accumulation of tech and security debt in your company.
Drawing on my experience in securing technology startups and software companies, I wrote a guest blog for ISACA on how to embed security in the modern product development. You can check it out here.
Bug bounty programmes are becoming the norm in larger software organisations but it doesn’t mean you have to be Google or Facebook to run one for continuous security testing and engaging with the security community..
Setting it up can be easier than you might think as there are multiple platforms like HackerOne, BugCrowd or similar out there that can help with centralised management. They also offer an option to introduce it gradually through private participation first before opening it to the whole world.
At a minimum, you can have a dedicated email address (e.g. security@yourexamplecompanyname) that security researchers can use to report security issues. Having a page transparently explaining the participation terms, scope and payout rate also helps. Additionally, it’s good to have appropriate tooling to track issues and verify fixes.
Even if you don’t have any of the above, security researchers can still find vulnerabilities in your product and report them to you responsibly, so you effectively get free testing but can exercise limited control over it. Therefore, it’s a good idea to have a process in place to keep them happy enough to avoid them disclosing issues publicly.
There is probably nothing more frustrating for a security researcher than receiving no response (apart perhaps from being threatened legal action), so communication is key. At the very least, thank them and request more information to help verify their finding while you kick off the investigation internally. Bonus points for keeping them in the loop when it comes to plans for remediation, if appropriate.
There are some prerequisites for setting up the bug bounty programme though. Beyond the obvious budget requirement for paying researchers for the vulnerabilities they discover, there is a broader need for engineering resources being available to analyse reported issues and work on improving the security of your products and services. What’s the point of setting up a bug bounty programme if no one is looking at the findings?
Many companies, therefore, might feel they are not ready for a bug bounty programme. They may have too many known issues already and fear they will be overwhelmed with duplicate submissions. These might indeed be problematic to manage, so such organisations are better off focusing their efforts on remediating known vulnerabilities and implementing measures to prevent them (e.g. setting up a Content Security Policy).
They could also consider introducing security tests in the pipeline as this will help catch potential vulnerabilities much earlier in the process, so the bug bounty programme can be used as a fall back mechanism, not the primary way for identifying security issues.
