Menu
When we hear the word “champion”, we instinctively think of someone that excels at a given task, and that they are not only the best at what they do, but have established themselves as such by competing with others in a championship in order to be crowned the winner. This is certainly the most typical meaning of the word historically and stems from the Anglo-Saxon word “cempa” (meaning “warrior”) from the Latin campio: the victor in a challenge, contest or competition.
We’re all familiar with the story of David and Goliath, in which two opposing armies pick a champion from among their ranks in order to perform an individual trial by combat, each combatant championing the cause of one side. “Champion warfare” of this form is very common through ancient history, myths and epics.
However, there is a second, slightly different meaning to being a “champion” in which an individual or organisation may champion a cause in a more abstract way: not engaging in direct competition or proving themselves the best, but by evangelizing for a given position or cause. In this second sense, a champion can be either a visionary advocate who popularizes and spreads an idea, or merely someone that promotes and argues for it.
It is this second meaning of the word that applies to security champions: rather than being individuals that necessarily excel in security, they might advocate for it within an environment where there may be either a resistance to it, or an absence of consideration for or knowledge of it. As we shall see, security champions do not in fact need to be first-rate security experts themselves.
A security champion is instead someone that promotes the cause of security, and whilst they are security-aware, they do not themselves need to be security experts. The key differentiator between a security champion and other security personnel is that a security champion is not part of the security team, but is embedded within functional (delivery) teams. BSIMM (Building Security in Maturity Model) group that tracks cybersecurity initiatives describes security champions as “satellite members” – individuals scattered across an organization who show an above-average level of security interest that can help improve security in their existing position, rather than being employed in a full-time security role.
Because they are embedded within functional delivery teams, security champions will typically have a slightly different focus and area of concern to formal information security teams. Central infosec teams may focus predominantly on centralised and centrally-managed controls and concerns such as network infrastructure, firewall and server security, operating system security, Intrusion Detection Systems (IDS), logging and monitoring, security policies, and end-use security. Security champions on the other hand are embedded within development teams and their security remit will apply to these higher-level, typically application-layer concerns such as code quality, Continuous Integration/Deployment (CI/CD), secure coding practices, the use of secure frameworks, third party and included open-source code assurance, quality assurance and testing.
Within recent years, many organisations have sought to leverage new paradigms for software development that reduce time to market and risk by performing smaller, more frequent software deployments and gaining rapid feedback on changes introduced. Whilst not always the case, security teams have been characterised as failing to adapt to and integrate with these new paradigms. Security teams are often represented as attempting to burden lightweight and agile SDLC workflows with stodgily traditional, slow, and reactive assurance methods. This creates so-called “security gates” late in the development flow that function as hurdles or barriers, with code blocked from release at the last moment. This can cause frustration with development teams and product owners faced with delay, rework, implied criticism, and a slower overall product delivery. Accusations can be levied that teams are held to account at a late stage and against measures that they had no prior warning of.
In reaction to this pressure and seeking how to best support the paradigmatic shift in development practices more effectively, there has been much discussion of how best to “shift security left” within the SDLC – meaning how to front-load security earlier, where it is cheaper and more easily addressed.
It is as a bridge between the development team and the security team that security champions are positioned as a partial solution.
For central security teams, security champions are positioned as offering a way of gaining a much closer, granular visibility and native understanding of potential security issues within development workflows. The security champion is acting from the “inside-out,” rather than “outside-in” and so has greater visibility of potential concerns. It can be difficult to provide robust assurance and challenge of practices from an external perspective (outside the development team) because you have to know what is going before you can even ask the right questions. Security champions offer a way to increase security influence earlier in the development cycle and ensure that security is considered and built into development processes rather than a last-minute bolt-on assessment that may be skipped, bypassed, or overridden by teams under pressure of delivery timescales and commitments.
For the development team, an insight into security concerns can provide more efficient resolution of security issues by spotting poor patterns or practices that can be amended or replaced to remove even the possibility of certain classes of problems. This is more efficient than reactively “spot-fixing” individual security issues that are reported back to them on a case-by-case basis only at time of deployment under security team quality gates. For example, by introducing tooling to perform dependency checks, potential vulnerabilities within third-party libraries or components used can be avoided before they are even introduced.
For both teams, the benefits of introducing and embedding security champions lies in ensuring that there is a channel for the constant bi-directional conversation on security concerns, which benefits both teams.
The exact tasks performed by security champions vary between those that have adopted the practice, since there is no formal model or pattern for how best to deploy them, and each organisation will face slightly different challenges. The closest to a formal pattern that can be followed in introducing security champions may be the OWASP “Security Champions Playbook.” According to the OWASP definition, security champions act primarily as “canaries” within development teams that “may help to make decisions about when to engage the security team“.
Adobe, on the other hand, in their own security champion programme specifically argue for security champions to be used as uni-directional security evangelists, to “disseminat[e] critical security information to and ensuring the completion of security tasks within their product or service teams“.
SAFECode meanwhile believe that security champions should be responsible for “identifying and solving security issues early in the software development lifecycle (SDLC)…responsible for (among other things) code review and architectural analysis efforts, contribute to security awareness, and help integrate security into the SDLC. ”
All of these are valid options, and most organisations will likely use some combination of these functions to address the specific concerns and issues that it faces.
Practical DevSecOps are one of the first organizations to offer formal certification for security champions under their “Certified Security Champion” certification, which largely focuses on security awareness around specific vulnerabilities. However, most other proponents of security champions argue that other factors, such as a passion for an interest in security – and talking about security – are more important than absolute security knowledge.
Most proponents of security champions argue that the ideal candidate should be a developer, or at the least strongly conversant in the software development tools and methodologies used within the organisation: that hiring a “security person” and expecting that person to swoop in to fix security problems within a development team is a doomed strategy. The preferred approach is to take a developer and train them to an awareness (rather than practitioner) level of security knowledge If needed, rather than taking a security expert and trying to get them to understand development team processes. The “domain knowledge” of how the development workflow operates is vital in identifying potential problems that represent opportunities for improvement.
However, it is the greater framework of support that is emphasised most often, rather than individual knowledge possessed by the security champion. In particular, the security champion needs to be empowered to act, which requires both a level of support for the programme, as well as a minimum degree of both “visibility” and “clout” for the security champion.
Rather than rely on authority in the typical sense, however, and establishing an antagonistic relationship, the favoured approach is to pick security champions that are listened to because they are well respected and approachable. This can mean ensuring that they have sufficient time available on top of their “day job” to effectively perform the security functions needed, and be enthusiastic, approachable, and willing to function as a resource for their peers, answering questions and mentoring them on secure coding best practices as needed.
This can mean that an emphasis of “soft skills” can be more critical in ensuring the success of a security champion programme. Security champions are more likely to succeed if they can successfully negotiate potential hurdles with skills such as conflict resolution, discursive and explanatory skills, and simply inspiring or motivating others rather than appearing as critical.
The OWASP security champion playbook lays out a detailed “best practice” plan for how a security champion programme can be rolled out. It consists of identifying teams that would benefit from security champions being embedded within them; defining the role; nominating or selecting champions; setting up communication channels to security teams; building knowledge bases to document knowledge and shared learnings and ensure consistency of messaging; and then maintaining interest in the programme and “evangelizing for the evangelists.”
In larger organisations, there may be a network of security champions embedded within different development teams. There are benefits to ensuring that these distributed champions are able to communicate with one another: they can share learnings on encountered issues and solutions, share knowledge, and simply motivate one another in mutual support of what is a shared interest that they have in common.
This can be done creating an online group, forum, or email group, but within Agile development the favoured method is to encourage the creation of “guilds” that group individuals with similar skills or interests but are drawn from across different teams. The difference is that there is an increased focus within guilds on face-to-face interaction, a broad and self-nominated membership (not limited to security champions, but anyone with an interest in security) and encouraging activities such as “capture the flag” games and social gatherings that provide an emphasis on engagement and motivation rather than knowledge transfer alone.
It is certainly possible to introduce a security champion programme that fails to deliver on objectives. If champions are misunderstood as being champions in the “victor” sense, as someone who has responsibility for security there can be a tendency for other team members to simply not concern themselves with security and to assume that they have devolved all responsibility for security to them. This is the exact opposite of the evangelization of security that security champions are intended to encourage.
It is also possible for security champions to be used to shortcut security, if decisions that would have been deferred to a central security team previously are instead presented to the locally embedded security champion who is seen as a “soft touch”: being a developer themselves they may be more sensitive to development concerns, as well as less knowledgeable about potential risks.
The overall benefits delivered by a security champions programme are generally thought to be a net positive benefit to a security management system, and an effective solution for responding to the paradigmatic changes being seen within software development teams and processes within many organisations.
AppCheck can help you with providing assurance in your entire organisation’s security footprint, by detecting vulnerabilities and enabling organizations to remediate them before attackers are able to exploit them. AppCheck performs comprehensive checks for a massive range of web application and infrastructure vulnerabilities – including missing security patches, exposed network services and default or insecure authentication in place in infrastructure devices.
External vulnerability scanning secures the perimeter of your network from external threats, such as cyber criminals seeking to exploit or disrupt your internet facing infrastructure. Our state-of-the-art external vulnerability scanner can assist in strengthening and bolstering your external networks, which are most prone to attack due to their ease of access.
The AppCheck vulnerability analysis engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please contact us: info@appcheck-ng.com
No software to download or install.
Contact us or call us 0113 887 8380
