This article is based on an interview originally published on exchange.telstra.com featuring Hannah McKelvie, DevOps Security Senior Lead at Telstra.
Introduction
Hannah McKelvie leads a team of security specialists and testers at Telstra’s Perth office. In her role as DevOps Security Senior Lead, she is responsible for embedding cyber security into the organisation’s software delivery pipelines. In this interview, she shares how Telstra has rethought its approach to security to keep pace with modern continuous delivery practices.
What Is DevSecOps — and Why Does It Matter?
In a traditional software development workflow, security review happens late in the release cycle. A dedicated security team validates what the development team has built before it ships. This gate-based model works at slow release cadences, but it creates a bottleneck when teams want to deploy to production frequently — sometimes multiple times a day.
DevSecOps addresses this by integrating security into every stage of the development lifecycle rather than treating it as a final checkpoint. As Hannah explains:
“Our challenge is to figure out how to provide the same cyber security expertise but with much greater speed. Our solution is to make sure there is close collaboration between our security and DevOps teams, which has resulted in a shared accountability strategy.”
Hannah McKelvie, DevOps Security Senior Lead, Telstra
The key shift in DevSecOps is cultural as much as technical: security stops being the responsibility of a single siloed team and becomes a shared responsibility across every engineer who touches the codebase.
How Telstra Embedded Security Into Its DevOps Teams
Telstra’s approach evolved through two broad phases:
Phase 1: Co-Location and Incubation
In the early stages, Telstra embedded security subject matter experts directly within DevOps teams. These specialists worked alongside developers in the same physical space, providing real-time security advice, governance guidance, and on-the-job skills uplift. They also introduced early automated security scanning tools into the development workflow, shifting security checks left in the pipeline so problems could be caught earlier and fixed faster.
Phase 2: The Security Champion Program
As the DevSecOps culture matured, Telstra identified developers within each team who were motivated to improve the security quality of their own code. These individuals were enrolled in a formal Security Champion Program. The programme includes:
- Structured training sessions covering security fundamentals and secure coding practices
- Technical deep-dives on vulnerabilities relevant to the team’s technology stack
- Competitive code remediation challenges hosted on online platforms, where engineers practice identifying and fixing real-world security issues in a gamified environment
Security Champions act as advocates within their teams, raising the priority of security issues in sprint planning and keeping the team accountable for fixing vulnerabilities rather than deferring them indefinitely.
Balancing Security With Continuous Delivery: Practical Tips
One of the most common tensions in DevSecOps is the perceived trade-off between delivery speed and thorough security review. Hannah offers a risk-based framework for resolving that tension:
1. Adopt a Risk-Based Prioritisation Model
Not all work carries the same security risk. Prioritise higher-risk features and services for delivery by teams that have more mature security practices and tooling. This means complex, sensitive workloads get the scrutiny they need without slowing down lower-risk delivery streams.
2. Include Security Bugs in the Team Backlog
Security bugs are technical debt. If they live in a separate system that development teams never look at, they tend to accumulate. Telstra’s Security Champions advocate for security issues to be logged directly in the DevOps team’s backlog alongside functional bugs and feature work. This makes security visible to the whole team and keeps security debt from quietly growing.
3. Automate Wherever Possible
Automated security scanning — including static application security testing (SAST), dependency vulnerability scanning, and infrastructure-as-code analysis — removes the need for manual review of well-understood issue classes. Automation frees human security expertise for higher-order threat modelling and architecture review work that genuinely requires judgement.
4. Build Shared Accountability
Developers who understand security requirements and own security outcomes in their own code are faster and more effective than a central security gate staffed by a small team reviewing everything at the last minute. Shared accountability is not about removing specialist expertise — it is about distributing enough knowledge so that every engineer can make good security decisions day to day.
Key Takeaways for DevOps Teams
- Shift security left — integrate scanning and security review into CI/CD pipelines, not after them.
- Co-locate security expertise with development teams during early adoption phases to build relationships and trust.
- Invest in Security Champion programmes to scale security knowledge without scaling a central security headcount at the same rate.
- Treat security bugs as first-class backlog items so they are prioritised and fixed, not deferred.
- Use risk-based thinking to match the maturity of security controls to the risk profile of the work being delivered.
The Telstra experience illustrates a broader principle: the fastest path to secure software at scale is not more gatekeeping — it is better-informed engineers supported by the right tools, training, and culture.