A security champion is a developer with a vested interest in security who helps to amplify the security message at the team level. Security champions don’t need to be security experts; they just need to act as the security heartbeat of the team, keeping their eyes and ears open for potential problems. In turn, once the team is aware of these issues, it can then either ﬁx the issues in development or call in your organization’s security experts to provide guidance.
In this blog, I'll give a high-level view into necessary steps before building your security champions program, the individual and organizational benefits, along with common pitfalls to avoid, as well.
Before getting started, take inventory of all the pieces that make up your application (languages in use, data flow diagrams, components (if using CDN/cloud providers), and a complete list of all code repositories currently being utilized.
You'll also want to generate appropriate documentation in terms of how and what data flows through the application, as well as API documentation/resources like Swagger docs or Postman collections, for example.
This should go without saying, but you want to house all this information in one place like Confluence or a similar wiki solution, as well as regularly review this information and update/archive, as necessary.
As you’re taking this inventory and documenting items, you'll want to think about the low-hanging fruit that's next in the queue. Essentially, ask yourself, “What’s the lowest amount of effort to get the greatest amount of return?" Oftentimes this can be a correlation of logs into one central place so you have greater insight into your apps.
So, why are we doing this? It's important to have a well-documented inventory before starting your CI/CD pipeline in order to bake in security and set expectations for timelines. If you don't have an accurate assessment of how many apps you have, where they're hosted, and what their purposes are, then you don't have a holistic security strategy. With CI/CD pipelines, you can incorporate security throughout the SLDC and failure to do so will result in teams needing to be reactionary— instead of being proactive to security issues. This leads to projects getting off schedule and/or over budget.
dynamic application security testing (dast)
Another key component is introducing a Dynamic Application Security Testing tool (DAST). These are tools that you can roll your apps into these platforms to perform high-level scanning on your behalf. It may take time to tune your sensors for things you’re looking for, but by having an automated process, you’re uncovering more vulnerabilities on a regular basis -- instead of conducting manual-based assessments.
By setting regular intervals for scanning, you’re going to get better insights into issues within your environment. When you uncover these issues, triaging for these vulnerabilities is massively accelerated because you’re finding these earlier in the software development lifecycle. While setting up a DAST platform isn't the easiest task, you'll likely find 60-to-70 percent of bugs in your code using this method.
slide to the left
I can't stress the importance of "shifting left" to find vulnerabilities earlier in the lifecycle to begin creating your security champions program.
If you had to boil it down, shifting left is finding vulnerabilities in the lifecycle — essentially, you’re pushing discovery of these things earlier so you can react and triage. Once you’re able to do those things, you'll be able to stand up a CI/CD pipeline with more ease.
Incorporating this shifting left mentality, you’re now able to focus on preventing vulnerabilities from entering the lifecycle, which makes building your security champions program that much easier.
When beginning to structure your security champions program, it's important to start small with one person on each of your dedicated development teams as a dedicated SME.
What that means is this person will assume an additional responsibility of being the security POC for that dev team to regularly interact with your app sec vulnerability team. In order to execute this and have smart conversations with your app sec teams, your contact will need to go through additional security training around secure coding best practices.
Secure coding is one thing, but I can't stress the importance of continued training. For instance, if your app is on a Kubernetes cluster and you’re doing it as infrastructure as code, then you’ll need additional training on what’s the best way to set this app as it functions on Kubernetes. Some companies will push that down to the product team, but it's important to own aspects of the products.
If you’re looking at developers, then training your security champions is going to be something that’s going to take time and dedicated resources. That's where nVisium can step in with our DevSec Mentor platform, as well as staff augmentation capabilities.
Every company is different, but by designating a security champion, you’re effectively extending the app sec team’s reach — allowing more time to focus on digital transformation as a whole. Most app sec teams aren’t 30 people deep and in most cases, they can range from three-to-six people teams depending on the size of the company.
If you have a company that has 2,000 applications and you only have six people on your app sec team, you're bound to run into issues. By working to get ahead of that with training and working with security champions, you’re now working at a more manageable level. You’re also providing the app sec team direction and guidance that security champions can implement within their own teams.
TAKING CARE OF BUSINESS (LOGIC)
Another advantage of having a security champion is the ability to see an app through a business logic lens. They’re not looking specifically for, “Does the app work or is it functional?”— but also looking at the business logic within the app. For example, are you doing any sort of sanitization of user input? Or maybe you’re looking at common web app vulnerabilities — some of which are easier to see in source code rather than browsers.
My team at nVisium also places business logic at the forefront when working with clients. If you're having trouble discerning what makes sense, our consultants can help clear up any grey areas to help you move forward.
Getting buy-in on your security champions program is critical. It’s not just buy-in from your dev teams, but you also have to get buy-in from your senior leadership, too. Some common buy-in issues include leadership who can't see the long-term benefits or not being able to see the big picture since it's outside their lane(s).
The process becomes a lot easier when you have leadership on board with a directive and that they support the initiative to provide value to the customers. Because, oftentimes, there’s contention when it’s a new program being rolled in because they’re already backed up to begin with.
COMMUNICATION IS KEY
Another aspect of a world-class app sec program is that you need to operate in a team environment. I know that sounds like a cliche, but if you’re not effectively communicating from the app sec team to the dev or product teams, major problems will arise. One way of informing your product teams, as well as influencing them, is putting in place incentives or directives to follow the program.
HOW WE CAN HELP
nVisium empowers organizations to eliminate application and cloud security vulnerabilities before cyber threats exploit them with proven in-depth security assessments, remediation, and training programs. Our penetration testers emulate a sophisticated attacker and exploit your networked devices, endpoints, and servers to reduce risks before breaches occur.
Give us a call when you start your software developer security training strategy update or better yet, schedule a consultation today.
Lastly, download our eBook, “Demystifying DevSecOps,” to get started yourself.