AI is making it easier for more people to build software, which is changing the scale and shape of security risk.
In this Security Edge discussion, Daniel Kreitals, Senior Solutions Engineer at Wiz, and Stefan Shrekat, CISO at Reece Australia, examined what it takes to keep security effective when development is moving faster, spreading wider, and reaching further into the business.
Their focus was practical: better visibility, clearer prioritisation, and a security model that could scale by being shared more broadly across the organisation.
Key takeaways:
- AI is widening the attack surface by making software creation faster and more accessible across the business.
- Security teams need end to end visibility across code, cloud, and runtime to manage risk in modern development environments.
- Security scales more effectively when teams can self serve, act on contextualised risk, and treat security as part of delivery rather than a separate gate.
AI is expanding software creation and widening the attack surface
AI is lowering the barrier to building software, and that is changing who creates risk.
Development is no longer confined to trained engineers.
Teams across marketing, HR, and operations are starting to build with AI assisted tools, increasing the number of systems, workflows, and dependencies security teams need to understand.
Daniel pointed to the rise of AI assisted development and so called vibe coding as a shift that was speeding up experimentation while also introducing new supply chain and lifecycle risks.
The same technologies helping organisations build faster are also giving attackers faster ways to find and exploit weaknesses.
That puts more pressure on security teams to understand how software is being created, where exposure is being introduced, and how quickly those conditions are changing.
Security needs visibility across code, cloud, and runtime
The discussion made clear that fragmented security models are struggling to keep up.
AI systems and modern applications move across identities, infrastructure, data, and applications, which means point controls are no longer enough.
Daniel described a more complete model built around understanding what is being built in code, how it is running in infrastructure, and what it is doing at runtime.
That full view gives organisations a better chance of spotting risk earlier and responding before issues move deeper into production.
Without that visibility, security teams are left reacting to disconnected signals while the underlying environment grows more complex.
Reece scaled security by making it easier for teams to own risk
Stefan explained that security only scales when more of the organisation can act on it directly.
At Reece Australia, a small central security team supports more than 200 developers, which makes traditional gatekeeping unrealistic.
Their answer was to push security insight closer to the teams doing the work.
That meant enabling self service access to security findings so developers and product teams could identify and remediate issues themselves.
In practice, this turned security into a more distributed capability rather than a function owned by a small central group.
The shift mattered because it matched the speed of development more closely and reduced the lag between identifying a problem and fixing it.
Better prioritisation starts with context, not more findings
The discussion also pushed back on the idea that more visibility automatically creates better outcomes.
Flooding teams with thousands of vulnerabilities often creates fatigue rather than progress.
Reece’s approach was to move away from raw vulnerability reporting and focus instead on issues that carried clearer business relevance, such as those that were exploitable, internet facing, or tied to sensitive data.
That change improved engagement because teams could see what mattered first.
It also helped security conversations become more useful. Rather than reporting risk as noise, the organisation could frame it in terms of exposure and business impact, making action easier to prioritise.
Security gets stronger when teams trust it and see its relevance
Stefan also described a cultural shift in how security was being received.
Teams engage more readily when security helps them move toward business goals instead of interrupting them without context.
Over time, that changes the relationship. Security becomes part of delivery rather than something applied from the outside.
At Reece, that meant conversations were moving away from reactive reporting and toward earlier collaboration, including around future issues such as AI security. The broader message was clear.
Organisations move faster and more safely when security is embedded into the way teams already work, supported by trust, relevance, and enough shared ownership to keep up with change.