The Definitive Guide to Developer Adoption
Getting your development teams to accept and ultimately adopt the processes, tools, and techniques you introduce can be tough. But the threat to your supply chain is real, and you need developers on your side.
You need them. They need you.
Your software supply chain is under threat – that much, you already know. Components can be of low quality, introduce critical vulnerabilities into your apps, or carry licenses that are incompatible with your organization’s business goals. Worse, next-gen attacks are compromising components at the source.
So, naturally, you want to secure your software supply chain, and that means rolling out new processes, techniques, and tools. In other words, a cohesive strategy that everyone adheres to, developers included. Meanwhile, developers need speed and efficiency, and have worked hard to eliminate complications and blockers.
So you’re at an impasse. Your need for a cohesive strategy conflicts with their need for efficiency.
But it’s not an impossible problem. In this guide, we talk about the ways to get your developers to adopt the processes, techniques, and tools you provide for securing your software supply chain.
As you’ll see, it’s a journey, and not exactly short. To help you along, we’ve structured our guide in the familiar crawl/walk/run/sprint model and provided some key action items for each stage – not exhaustive, but a good place to start! You’ll notice that lots of the action items are about communicating, and that’s not a coincidence.
If you take nothing else from this guide, take this: the keys to getting Developer adoption are understanding, respect, and (most of all) communication. Talking about what you need, and listening to developers about what they need, will yield results.
Crawl: Executive Sponsorship
Efforts to encourage adoption can’t get off the ground unless an executive sponsor agrees that securing your software supply chain is an organizational priority. If you don’t already have an executive sponsor, you need to find one. It will be very difficult to continue otherwise. Luckily, the issue of software supply chain security is an increasingly important one. It’s likely that your organization’s executives are familiar with the concept already.
As for how to get the executive sponsorship, there’s no single path. Start by identifying the executive closest to your role/title, and the executives closest to your developers. Depending on the size and complexity of your organization, these could be VPs, Directors, or even the CTO.
From there, the goal is to have them agree that securing the software supply chain is critical. Now’s the time to give a presentation, show them the risks, and paint a picture of the worst-case scenario. Be realistic; scare tactics won’t get you results. But don’t pull any punches, either. See the checklist below for some strategies.
Then grab some data, both real and theoretical, and focus on the cost of solving a component issue early with the cost of solving a component issue very late. Hold on to that info – it will be useful when talking to developers later.
If you find a willing sponsor, focus on turning that cooperation into something shareable, like a statement or policy.
Influencing your organization’s priorities isn’t easy, and may be not possible depending on your role. You may need to set your sights a little smaller to start. But get the conversation started anyway! This is a pressing issue, and addressing it is key.
Checklist to help you prepare.
Identify the executive closest to your role/title.
- What is your organization’s current relationship to the supply chain?
- Is your organization doing anything to protect themselves and their assets?
- What changes can you make in the short term/long term to secure the supply chain?
Prepare some data. Compare:
- The cost to block a bad component when a developer tries to download it.
- The cost to fix a bad component once it’s in your repository.
- The cost to fix a bad component once it’s part of a build.
- The cost to fix a bad component once the product is released.
Look for allies in your organization. Approach information security, application security, legal, operations, engineering, development, and others.
Meet with potential allies and ask:
- How might a failure in the software supply chain affect them?
- Are they doing anything ad hoc to try and secure the supply chain?
- What’s their immediate recommendation?
Meet with an executive.
- Get your allies involved. Invite them to the meeting and prep them ahead of time.
- Share your data from the first checklist item.
- Paint them a picture of the state of the software supply chain and discuss the following:
- Discuss the 2022 State of the Software Supply Chain Report.
- Next-gen attack vectors (compromising components at the source).
- Disruptions to the supply chain and their associated cost.
Walk: Build Trust with Developers
Once you have executive sponsorship, it’s time to start talking with your development teams. Talk to whoever you have an existing relationship with, be it middle managers or junior devs. Get a sense of their needs and communicate your own. Though their priorities are different from yours, you’ll find there’s important overlap.
Once you’ve made some connections, take the trust a little further by asking for Developer Advocates. These are individuals who will work closely with you and represent the needs and concerns of their fellow developers. You’ll likely find that Developer Advocates are the senior-most members of their respective teams. Regardless, you’ll need a few. If you ask sincerely for their cooperation, you’re likely to get it.
Your workflows need to be low-friction for developers to adopt, and Developer Advocates are the key to making that happen. Get them involved in building your workflows early. Encourage them to call out points of friction – where the process seems slow, where work is duplicated, etc. What’s bad for developers is bad for you, so take feedback seriously.
Here’s a hint: automation is how you’ll reduce friction. Think about what can be automated before talking to Developer Advocates, and ask them what else they’d like to see automated. Not only will automation save developers time and heartache, but it proves that keeping friction low is a priority of yours, which further builds trust.
Another way to build trust with developers is to put power into the developers’ hands. “Shift Left” is sometimes summarized as giving developers more responsibility. But it’s really about giving developers more resources. For example, if your strategy to secure the supply chain includes scanning components for risks (and it should), make sure that developers have access to the same tool, configured identically, so they can scan for themselves and see what you see.
Building trust is also about listening. Be an active listener, and address questions and concerns head-on. It’s okay to say “I don’t know yet” or “We haven’t decided”. The only truly unacceptable response is to ignore them.
As you can see, building trust is about building and using communication channels. Communication builds trust, especially if that communication is proactive and reciprocal.
Checklist to help you prepare.
- Meet with developers you know and introduce yourself to developers you don’t.
- Ask them questions like:
- What metrics are they being graded on? (Speed? Productivity?)
- Where do they do their development? (e.g. with an IDE?)
- What roadblocks are they currently facing, on an institutional level?
- What do they know about the software supply chain?
- Announce to them that you’re developing plans to try and secure the software supply chain. Ask for their cooperation.
- Ask them questions like:
Ask for Developer Advocates. Try to have broad representation amongst developer teams.
Share your anticipated workflows with Developer Advocates. Ask for feedback. Identify points of friction. Repeat.
Have some resources to put into developers’ hands, such as:
- Educational/training resource for any new tools you need to introduce.
- Access to the tools that will be used to scan components for risks.
- Suggestions for automating anything boring and manual.
- Further consider:
- Can you help them free up time for securing the supply chain?
- Can you get them rewarded for adhering to your strategy?
- Can you get them assistance during the rollout of any new processes/techniques/tools?
Prepare some data. Compare:
- The cost to block a bad component when a developer tries to download it.
- The cost to fix a bad component once it’s in your repository.
- The cost to fix a bad component once it’s part of a build.
- The cost to fix a bad component once the product is released.
Meet with potential allies and ask:
- How might a failure in the software supply chain affect them?
- Are they doing anything ad hoc to try and secure the supply chain?
- What’s their immediate recommendation?
Meet with an executive.
- Get your allies involved. Invite them to the meeting and prep them ahead of time.
- Share your data from the first checklist item.
- Paint them a picture of the state of the software supply chain and discuss the following:
- Discuss the 2022 State of the Software Supply Chain Report.
- Next-gen attack vectors (compromising components at the source).
- Disruptions to the supply chain and their associated cost.
Run: Communicate Responsibility and Expectations
If your processes, techniques, and tools are ambiguous, they won’t be adopted. You wouldn’t get in line without knowing what the line is for, and developers won’t, either.
Now’s the time to communicate all the specifics of the workflows you need developers to follow. Be precise. Call out when, who, where, and how, with a particular focus on where and how someone will get blocked.
Call out responsibilities. For example, who is responsible for deciding if a component and its associated risk is acceptable? In the case that it’s not acceptable, who is responsible for addressing that problem? You may call these responsibilities SLOs (Service Level Obligations), and the responsible parties might be a person or a group of people. They might even be you!
Also be sure that developers know how to get unblocked. Securing your software supply chain means occasionally saying “no” to a risky component. Make it clear how that blocking action will occur, and what a developer should do next. It’s also true that developers will occasionally need to say “yes” when you’ve said “no” – so also make it clear how and where developers can argue the point.
Whatever your process actually is, it needs to be documented somewhere. Build an internal resource like a wiki, and state processes and workflows in plain language. Maintenance of this resource should be a priority. If what the wiki says and what you say don’t match, then it will be difficult to trust either.
Finally, as often as necessary, set up a demo or simulate an event to catch any gaps. If something isn’t clear, or a responsibility hasn’t been assigned, a simulation will catch it. Invite Developer Advocates to participate, and get their feedback.
Checklist to help you prepare.
Meet with developer advocates and stakeholders and discuss responsibility. Try to determine the person responsible for each of the following:
- Setting the organization’s overall risk tolerance.
- Setting an application’s individual risk tolerance.
- Scanning and reviewing applications for component issues.
- Making exceptions, when appropriate.
Build an internal resource like a wiki for documenting your processes and workflows. Make sure it includes, at a minimum:
- When apps should be scanned/reviewed for component risks.
- A statement about your organization’s overall component risk tolerance.
- Details about what sort of component risks aren’t acceptable and why.
- Details about when and where blocking or breaking will occur if such a risk is found in an application.
- Details about how a developer should try to address issues with components (i.e. remediation).
- Details about how a developer should ask for an exception/get unblocked.
Clarify the process for getting unblocked. Answer the following:
- Who is responsible for making the exception, when appropriate?
- Where should a developer submit their request?
- What sort of reasoning should a developer provide?
Prep a demo or a simulated event and perform that demo for developers. Ask for feedback and put a pin in any points of friction.
Sprint: Celebrate Success
Celebrating success doesn’t always come naturally to us. As problem-solvers, we see issues more easily than we see non-issues. But encouraging adoption requires that you find examples of the positive outcomes of your efforts and share them across your organization.
Grab a little data, interpret it, and share it broadly. For example, you might call out how many scans or reviews were performed over the last month, and then explain what that means for your risk posture. If scans found a critically vulnerable component (think: log4j) last month, but not this month, then congratulate the team who fixed it and discuss how much safer that application is now.
Contextualize the data. For example, if the total number of issues found during scans suddenly dropped, explain why. Maybe remediation was a priority this last sprint, or maybe a quick fix solved lots of issues all at once. On the other hand, if the number of issues found suddenly multiplies, maybe some new apps were scanned for the very first time, or maybe a new vulnerability was just discovered. In any case, context like this is the difference between noise and data, so provide it when you can.
Resist the urge to use good results to shame teams with bad results. Developers will not adopt if they think these metrics will be used against them or their peers. Instead, if you must editorialize, talk about how those good results came to be. Someone, somewhere, followed the process, thought critically, asked questions, etc., and that’s what you should focus on.
Checklist to help you prepare.
- The frequency that applications are scanned/reviewed for component vulnerabilities.
- The number of applications being scanned/reviewed.
- The number of bad or risky components that were blocked.
- The number of bad or risky components thta were upgraded or updated.
- The number of bad or risky components that were passed up for better ones.
- Brief snippets of any notable threats to the greater software supply chain.
- Updates on the rollout of any new tools, techniques, processes, etc.
- A brief summary of your key success metrics, e.g. “We scanned applications 700 times this week, blocked 31 known, malicious components”, etc.
- Highlight an individual or team who made addressing the software supply chain a priority.
It’s important to acknowledge that making a big, organizational change like this can be stressful and a little scary. It’s a little like buying a new jacket, jeans, or pair of shoes. Because they haven’t been “worn in” yet, they’ll feel a little uncomfortable.
But the keyword is “yet.” If your communication channels are open, and everyone’s collaborating, you will eventually build workflows that are customized to the unique needs, strengths, and personalities of your organization.
So get started early – preferably now! The sooner you ask your developers to adopt, the sooner you can begin “wearing in” the workflows and making them fit.