It’s no surprise that in the last few years, the way we develop applications has changed. Nearly all the ‘core’ elements we once associated with software development have been transformed owing to new tech, shifts in corporate culture, and market demands. For example, you don’t really have standalone ‘developers’ anymore. Instead, you have an engineering team that consists of Developers, DevOps, QA, and Engineering Management. Monthly releases have been replaced by ‘Continuous Delivery,’ where your engineering team deploys code to their git repo 10 times a day, which triggers a build workflow that pushes the code to a Container Image (OCI Compliant, at that). That container image automagically gets deployed to a cloud/Kubernetes environment using Argo, Tekton, or some other pull-based Continuous Deployment system. Phew, that was a mouthful.
The sort of development cycle I described has been the standard for quite some time now, and you wouldn’t so much as bat an eye at this overnight increase in complexity. And yet, there appears to be a weak link in the chain, one that’s introducing friction in this well-oiled machine and slowing it down. Ask yourself this: are you still running Application Security as a central team? Are you experiencing the following symptoms:
If you’ve answered ‘Yes’ to any of these questions, you already know you have a problem. Before you attempt to fix it, though, you need a radically new way of thinking about security. Let’s talk about that.
Yes, you read that right. I know how unintuitive it sounds, so let me explain. The engineering team knows their product in and out. They own the code, the engineering tools, the DevOps process. They own ‘quality’ of the product. But paradoxically, they DON’T own security. Somehow, we’ve been living in a weird reality where the engineering team owns quality, but not security. But there IS no quality without security. If you ask most industry professionals who work on software, here’s what they’ll tell you they want:
The whole perception of security and the role of the security team is upside down. For starters, security is a pretty specialised set of requirements and responsibilities. It’s not as simple as having a crack team swoop in and survey the situation, give a list of problems to be solved, and disappear into thin air.Security is a continuous process that needs to be embedded into multiple stages of the development lifecycle. And to do that, you need to have a decentralised approach to security, one that isn’t dependent on a single, isolated security team.This is where Champions come in.
Security champions are members of the engineering team who work as Developers, Architects, DevOps, etc. However, the critical difference is that they’re able to drive security initiatives and get the team to own and manage the security of the product they’re developing. Aside from sounding incredibly epic, champions are a great way to build a more resilient and sustainable security practice in the long run. Let’s look at how you can do that for your team as well.
First, let’s understand who can be a good security champion. A champion needs to be part of the engineering team in the role of a Developer, an Architect, or some other key position. They need to know the product well and have a good understanding of the tooling, constraints and processes adopted by the engineering team. A good security champion is someone who has a natural interest in application security and security-related problem-solving. For example, a champion could be a developer with a keen interest in cryptography, or a DevOps engineer who understands cloud security automation. Every engineering team has people like this. While their skills in security might vary, it’s important to start somewhere and not dwell too much on how proficient they are. A motivated professional can develop the skills they need over time. The key here is that they have a good attitude towards security and a rapport with other members of the engineer team.
Depending on how mature your security program is, create specific goals for your security champion(s). Objectives like “Implement SAST in PR and Git workflows by end of quarter,” or “Implement a secure default HTTP client library” are tangible and actionable. The idea is that your champion works with the rest of the engineering team to implement these goals. A good management framework would drive security as a key part of the team’s goals for the period.
While you chose your security champion because of their interest in security, that doesn’t necessarily mean experts at it. They may simply have a flair for it without knowing what to do about it. Training both your champion and engineering team in Application Security, Cloud Security, DevSecOps, Threat Modeling, etc. is vital to nurture their interest in the subject.Beyond simply equipping them with relevant skills, training helps instill a ‘spirit of security’ within your team. I’ve personally seen several instances where a combination of these trainings done through the year—preferably hands-on—can go a long way in bringing a clear vision for security in the team.
Looking for hands-on security training for your teams? Check out AppSecEngineer, our all-in-one AppSec learning platform with 30+ courses and 400+ hands-on labs!
Security champion(s) act as evangelists for security within the engineering team, like some kind of Messiah of Security expounding the virtues of good security practices. But to really get their team members’ attention, security needs to be made interesting to them.Champions should be given a set of security resources that they can use and share with the team at regular intervals. This can include useful OSS projects, interesting stories of exploits, security Twitter accounts to follow (like mine, haha) etc. This helps drive the message of security much more effectively within the team.
It’s important to remember that while champions have a new focus in security, they’re still doing their normal work as members of the engineering team. They need to know they’re being valued for the extra effort they’re making.Provide the right incentives (monetary or otherwise) for them to stay motivated and contribute to both their roles within the engineering team.Some of the most useful incentives I’ve seen provided are things like special conference budgets, bonuses, and special work perquisites.
If you’re an organisation with several engineering teams, have a community where security champions can reach out to each other to share experiences, solutions and help each other. This is especially useful for new champions who’d like to learn the ropes from more experienced employees.
Security automation is an underrated aspect of high quality application security programs. You need to establish a strong motivation and clear goalposts to ensure that champions and their corresponding engineering teams are given enough resources to automate mundane security tasks. Automation allows the entire team to focus only on issues that need special attention from humans, i.e., NOT issues that are a waste of precious man-hours.Security champions are an important ally for your organisation’s security program. Developing and nurturing them is a great way to scale up your application security efforts in an inclusive and organised, yet decentralised manner.Image credits:Featured imageby jcompTraining by FreepikStress by jcompAutomation by vectorjuice
