The Customer Education team at Sonatype has noticed that successful customers get started with Repository Firewall in a very specific way. I wanted to take a second to share some of that knowledge with you.
There are three policies that we encourage new Repository Firewall customers to turn on very early:
- Security-Namespace Conflict
These policies won’t disrupt your developers much, but provide huge defense against software supply chain attacks.
But how should you go about expanding quarantine to include other policies?
Successful customers start a pilot program. They take one high-performing dev team and expand quarantine for that team only. Then, over the course of a few weeks, they track the status of that team with regular touchpoint meetings. For example, one customer hosted Friday morning coffee talks. Another customer attended dev team morning stand-ups.
The goal of these meetings is to look for friction caused by the new quarantine rules. For example, if your pilot program dev team wonders why some components are being blocked, you need to communicate the rules better. Or, if they say that they don’t know how to request an exception, you need to formalize or refine a process for doing that.
(Remember, there will always be special cases that require an exception. Take the time to build that process out now.)
Once you’ve run the pilot program for a month or so, roll out your expanded quarantine to other dev teams. And, once all your dev teams have standardized, start the pilot program again for a new set of policies.
Here are some other quick tips.
The simplest way to find a high-performing dev team for your pilot program is to simply ask. Go to dev team leaders and ask how their teams are responding to Repository Firewall. Ideally, you want to find a team that has experienced quarantine before, but was able to solve the problem on their own.
Good policies to try in a pilot program are Security-Malicious and License-Banned. These policies target components that are so risky that most organizations can’t justify their use. That means you’ll want to roll them out to the whole organization as quickly as you can manage.
Once you have a pilot program, ask to attend those dev teams’ stand-ups or scrums. If you can’t, reach out regularly through channels your organization uses to communicate. If that’s not possible, schedule a chat with dev team leaders once every two weeks.
How have you gotten started with Repository Firewall? Did you try a pilot program? Is this strategy viable for your organization? Sound off in the comments below!