It was great to share my views on AI governance and the application of AI for cyber defence at the RSAC CISO Bootcamp.
I loved the audience participation – it’s a great community, and it’s a privilege to be able to exchange actionable tips with my peers.
Another wonderful day packed with practical sessions on cyber risk, board reporting, crisis response exercise practice, frontier AI model risk management, data breach mitigation and more.
Where else would you talk to the Deputy CISO of Anthropic and the former director of the US Cybersecurity and Infrastructure Security Agency (CISA) on the same day?
I recently gave a presentation on the Behavioural Analysis for Multi-Agent Systems. The idea at its centre is simple. AI agents drift from their intended goals in much the same way people drift from security policy, and psychology has spent decades learning to read that kind of behaviour. I explore some key themes in this blog.
I went to the Science Museum in London last week to see Charles Babbage’s Difference Engine No. 2 – eight thousand parts of brass and steel, working exactly as he drew it in the 1840s.
Babbage’s problem was banal: the mathematical tables of his era, used for navigation and engineering, were riddled with errors that humans kept introducing. His solution was clever. Many useful functions can be approximated by polynomials, and polynomials can be evaluated with nothing but repeated addition. Build a machine that adds reliably, and the errors disappear.
He never finished it. Funding ran out, his engineer quit, and his attention had already moved on to the Analytical Engine – a programmable, general-purpose machine with separate memory and processing units. He didn’t build that either. The contraption I was watching was assembled by the Science Museum between 1985 and 2002, mostly to settle whether Babbage’s drawings were buildable with Victorian engineering tolerances. They were. He was a hundred years early.
A lot of modern computer science is already implicit in the design. The split between data and operation we attribute to von Neumann. Punched-card input, borrowed from the Jacquard loom, that survived into the FORTRAN era. Ada Lovelace, writing notes on the unbuilt Analytical Engine, asking what it would mean for a machine to compute in general – a question we are still answering.
But the real legacy is the bet underneath all of it: that thinking, or some of it, is a physical process you can build out of parts. Every model we train and every program we write assumes Babbage was right.
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.
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.
A Causal Loop Diagram of The Happy Path Testing Pattern, Acquisition Archetypes, Carnegie Mellon University
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.
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.
