Open source software is part of our DNA at Rancher Labs (now part of SUSE). Unlike some of our competitors in the Kubernetes management space, we make 100% of our software available as open source. In all, we manage dozens of open source projects, which combine to pull in thousands of different dependencies.
Our love of open source includes an organization-wide commitment to using OSS in a sustainable and responsible manner. It is critical that we comply with open source licensing requirements and build projects free of major vulnerabilities — ideally without devoting too much precious engineering time to open source management.
When I joined Rancher Labs last year as a senior engineering manager, one of my first projects was to search for a comprehensive software composition analysis tool to help reduce license compliance and security risk. I ended up recommending FOSSA — a decision that’s served us well.
But simply deploying FOSSA was no guarantee of success. I knew our engineering, legal, and security teams would only gain maximum benefit if we conducted an effective implementation.
Looking back, I’m happy to say that we were able to accomplish this objective. In this blog, I’ll review four areas that contributed to our successful SCA implementation, with a particular focus on the value of making the process as easy as possible for my colleagues.
Note: This piece is based on the recent webinar: How Rancher Labs Increased Development Efficiency and Security with FOSSA. If you’re interested in this topic and would like more information, I’d recommend you view the on-demand version, which is linked below.
1. Keep it Simple — and Speedy
We approached SCA implementation with the goal of making the process extremely low-impact for everyone involved. We knew that a fast, simple implementation would not only limit disruption to existing engineering activities and workflows, but actually encourage team-wide adoption of the product.
Several factors contributed to our success in this area. One was a strong partnership with FOSSA, our SCA vendor. Their interface is easy to use, so there wasn’t a huge learning curve. It’s easy to see where dependencies are being detected and trace them down to where they might be being pulled in, especially those transitive dependencies.
Additionally, it was quite easy for us to set up customized alerts to ensure engineering managers, project managers, and developers were only notified of issues impacting their specific projects. These alerts are actionable and include guidance to support rapid remediation. This played a big role in getting company-wide buy-in: By making SCA and SCA implementation easy and light touch, we were able to prove value and ROI to the rest of the team quite quickly.
FOSSA also set up a dedicated Slack channel where my colleagues and I could get recommendations from their support team. (This is something that we continue to find useful; FOSSA has a large and highly technical support team that’s very quick to respond to any questions or feedback we may have.)
Additionally, to help introduce FOSSA to our broader team, we created a short presentation on using the product and triaging issues. We were able to share that internally and get engineers up to speed relatively quickly on what they needed to do to use the product effectively.
2. Integrate SCA with CI/CD
One of the early steps in our software composition analysis implementation journey included integrating FOSSA with our CI/CD system. We worked closely with FOSSA’s team to do this, and it ended up being a simple process. FOSSA’s next-gen scanning tool is written in Haskell and is very fast. Our centralized DevOps team was able to integrate scanning directly into the build and publish pipelines — even without the intervention of those engineering teams directly.
With this integration, we’re able to upload dependency data for analysis back to FOSSA with every CI build.
Our team at Rancher Labs uses a CI system that’s based on the Drone CI. And, we decided to go a step further and write a plug-in (which is just a few lines of YAML) to further simplify deployment. As you might expect given our open source ethos, we’ve open sourced that Drone plugin for FOSSA. You can access it on our GitHub page, and you may find it useful if you’re using Drone.
3. Remove Barriers to Access (Without Sacrificing Security)
Rancher Labs has a relatively large and sophisticated engineering organization, and we wanted to ensure that multiple teams and stakeholders were able to benefit from FOSSA.
We first used GitHub authentication to log into the FOSSA portal, but we’ve since upgraded that to Okta. This has made it much easier for the team to access FOSSA, especially for our legal and product users who don’t necessarily use GitHub extensively.
That’s not to say we made it a free for all. We used FOSSA’s RBAC (role-based access control) feature to grant access on an as-needed basis. As part of this process, we were also able to take advantage of FOSSA’s customized alerts, which I referenced earlier.
We have numerous different repositories at Rancher with different project managers and different engineering managers. FOSSA’s customized alerts ensure only the individuals whose projects are impacted by an issue are notified. When a CVE or license issue is detected, the engineering manager, project manager, and engineer assigned to security to that project automatically get an email.
Additionally, we were able to set up team-specific dashboards, which helped FOSSA scale with our growing use. These dashboards offer a single-pane-of-glass view into a team’s licensing and security posture across multiple repositories. Teams can also generate compliance reports and attribution notices from their FOSSA portals.
4. Plan to Address Initial Tech Debt
If your organization implements a sophisticated SCA tool like FOSSA, it’s likely that your first scan will include a few surprises. FOSSA scans for direct and transitive dependencies, and it did unearth a few licensing issues that we wanted to address and a few outdated dependencies that we wanted to update.
We divided that work among a handful of engineers and successfully cleared those issues within a few weeks — it took a handful of engineers a few spare hours each week to do this. Since clearing that initial tech debt, we’ve been able to shift to a much more proactive open source management posture.
The main lesson here is that open source scanning technology has evolved considerably in recent years. And, teams that adopt advanced tooling like FOSSA should account for the possibility that they will need to clear previously unknown issues that surface after the first scan.
Implementing Software Composition Analysis: The Bottom Line
Any time you implement new developer tooling — particularly technology that impacts many teams in the engineering organization and beyond — there’s always a chance you’ll face some hurdles. Fortunately, we at Rancher Labs enjoyed a successful and efficient SCA implementation.
As I reflect back, it’s clear the biggest reason for our success is that we were able to minimize disruption and make adoption very easy. This paved the way for my engineering, security, and legal colleagues to start using and getting results from FOSSA.
About the Author
Hayden Barnes is a senior engineering manager at Rancher Labs. He ran a technology law practice (Law Office of Hayden Barnes, LLC) before embarking on an engineering career. Hayden founded Whitewater Foundry, where he developed Pengwin Linux, joined Canonical to drive Ubuntu on WSL, and authored Pro Windows Subsystem for Linux (WSL): Powerful Tools and Practices for Cross-Platform Development and Collaboration. Hayden also organized WSLConf: the first community conference for WSL.
