When socializing a new security tool, it IS possible to build a bottom-up security culture where engineering has a seat at the table. Let's explore some effective strategies witnessed by the GitHub technical sales team to make this shift successful.
You heard the vendor pitches. You evaluated the options. You got the budget approved. Now, you need your company’s developers to actually use the tool.
Socializing a new security tool can feel intimidating or overwhelming. It may feel like you are battling competing priorities and culture conflicts. However, security has become a foundational responsibility of developers, and it is possible to build a bottom-up security culture where engineering has a seat at the table. Whether you are rolling out a developer-first solution like GitHub Advanced Security, or a traditional tool that targets security specialists, let’s explore some effective strategies witnessed by the GitHub team to make this shift successful.
Internal documentation is paramount for developers to feel empowered and supported when being given new tasks. Create a wiki with answers to common FAQ and flow charts to guide developers past common blockers. Source information from both the vendor’s resources and internal trial and error. It can be helpful to designate a single champion to take responsibility for updating and maintaining the wiki. Clearly lay out the process for developers to get support for issues that cannot be resolved through documentation.
Before the tool can be socialized, management needs to be clear on what their goals are. Understand what your definition of success is, how you will measure it, and the why behind it. Determine what timelines are achievable, and how expectations will be communicated. Make this a cross-team initiative for the best chance of success, including management from security, ops, and engineering. When a diverse set of teams with varying interests are able to design and communicate shared goals, the tool can sustainably become part of normal processes (and not become shelfware).
Publicly highlight development teams who are successfully utilizing the tool or doing something interesting with it, as opposed to calling attention to those that may be falling behind goals. At least at first, you want to introduce the tool as a place where developers can excel, and be high-performers, instead of another duty to add to their backlog. Lead with data, tracking metrics like number of closed vulnerabilities, or Mean Time To Remediation, and tie these numbers to your announcements for credibility. These efforts can help you organically grow a team of security champions from developers who exhibit passion or career growth motivations, while demonstrating correct usage of the tool.
Cultural shifts happen when security is built into the developer’s existing flow, as opposed to being injected as its own new stage in the pipeline. Look for points in their process where they are already in “pause” or “edit” mode, like at the Pull Request, where you can surface vulnerabilities and ask for remediation efforts. Doing so can avoid context switching and feelings of being interrupted. Capitalizing on an existing developer pause point can help train your developers to look at security vulnerabilities like functionality bugs, a skill they already have, while also shortening feedback loops.
Getting the highest level of management involved can help set the tone that security is a company-wide policy, and that it is business-critical. This can take the form of including security as a topic on calls led by executive leadership, or inviting your C-suite to briefly speak on the upcoming monthly engineering call. Not only does this express the importance and longevity of a new tool to your individual contributors, but it will help keep leadership abreast of the reductions in risk this new tool is achieving.
Quickstart efforts can be helpful as a complement to more sustainable longer-term goals. Consider a gamified event like an “in-house” bug bounty bash–a whole day devoted to tool education and getting rid of high criticality vulnerabilities. If engineering management is able to carve out time during a “learning day” or other type of free space in the sprint cycle, this effort can create immediate familiarity with the new tool (and build enthusiasm).
Developer-to-developer enablement is key. There is often a feeling of mistrust between engineering and security, but developers share the same interests and have the same priorities. Let individual contributors have an opportunity to educate and enable other individual contributors. If you have had a successful pilot or PoC team, or notice self-motivated folks using the tool proactively, give them space to share their experience with the tool. Not only will your high-performers build confidence in their security expertise, but the rest of the audience can see how the tool is used in their real, every-day environment. This enablement can standalone, or be included as part of larger management-led training.
All of these suggestions can help you implement a new security tool while keeping the focus on developer goals (getting features completed on schedule, solving interesting problems). Socializing a new security tool, the right way, will encourage the idea that security belongs to everyone.
We’ve dramatically increased 2FA adoption on GitHub as part of our responsibility to make the software ecosystem more secure. Read on to learn how we secured millions of developers and why we’re urging more organizations to join us in these efforts.
This blog post is an in-depth walkthrough on how we perform security research leveraging GitHub features, including code scanning, CodeQL, and Codespaces.
In this post, I’ll look at CVE-2023-6241, a vulnerability in the Arm Mali GPU that allows a malicious app to gain arbitrary kernel code execution and root on an Android phone. I’ll show how this vulnerability can be exploited even when Memory Tagging Extension (MTE), a powerful mitigation, is enabled on the device.
Shelby Gluck 
