We here at WhiteSource often get asked if we use our own software when we’re developing our product. It’s a fair question. Like most of our customers, we write a lot of code. A lot of code. And we want it to be secure. Really secure. So it should come as no surprise that the answer to this question is a resounding and absolute yes!
At WhiteSource, we believe in practicing what we preach. That means developing and releasing secure software using our own software composition analysis solution. Our development teams use our solution at every stage of the software development life cycle.
So how do we use our product? Read on as we take a look behind the scenes into how WhiteSource uses WhiteSource.
Our developers take different approaches to how they implement WhiteSource depending on their team’s individual focus. We talked to three WhiteSource R&D teams to learn more about how they are using WhiteSource in their day-to-day work.
The Unified Agent is our Java command-line tool that scans directories’ open source components for vulnerable libraries and source files, as well as license compliance. Results are uploaded to the WhiteSource web application to be viewed via a dashboard.
Not surprisingly, the R&D team that develops the Unified Agent also uses it to scan their code. The team follows the traditional WhiteSource data structure, where in our software, the top-level organization is named “WhiteSource OSS,” the next-level product is named “UA” for Unified Agent, and projects map to individual features being developed for the Unified Agent.
When working on a new feature, the team performs a scan using the Unified Agent before each commit is pushed to GitHub. If a vulnerability is found, a Jira ticket is automatically opened.
Fixes are done based on the priority of the vulnerability. Most of the time, fixes are easy because the UA team is constantly scanning their code and tracking vulnerabilities. Remediating one vulnerability at a time is not that difficult or labor intensive when you don’t have to deal with a backlog of open issues.
If a vulnerability is found in a direct dependency, using WhiteSource to upgrade to the newest version of an open source library easily remediates the issue. If the vulnerability is in a transitive dependency, more research may be required. Sometimes updating the parent library fixes the child, though sometimes the child may need to be updated on its own. In these cases, the UA team uses Merge Confidence to help decide whether an open source component is safe to update without breaking the build.
Because the UA team scans their code in Jenkins on each and every build, including the final build at the end of each sprint, they are able to detect and remediate vulnerabilities before the product is shipped to customers.
WhiteSource features a wide range of developer tools and integrations for developer environments such as repositories, package managers, build tools, and more. These developer-focused tools integrate into developers’ existing workflows and processes, making security a seamless part of the way in which they write code.
In the spirit of WhiteSource using Whitesource, the Developer Tools and Integrations R&D Team at WhiteSource uses the very same tools they create to actively detect and remediate security vulnerabilities in open source components. For them, it is the ultimate shift left.
When coding, the developers use the IDE integration to determine, from within their native development environment, whether an open source component has any security vulnerabilities or license compliance issues before a pull request is made and the open source component enters their codebase. In addition, from their repository before a new feature branch is merged into the main branch, the GitHub branch protection rule is configured to mandate that a WhiteSource security check is performed. If the WhiteSource security check fails, the merge is blocked. Developers can easily view a WhiteSource security report within GitHub that identifies the problematic package and lists its defects so it can be remediated.
If a brand new vulnerability is discovered in an existing open source component that is currently in production, WhiteSource automatically opens a Jira ticket so that the developer is alerted and can fix the issue.
In addition to continuously scanning their code using WhiteSource, the Analysis R&D team are heavy users of WhiteSource Prioritize. WhiteSource Prioritize identifies whether proprietary code is making calls to vulnerable functions to determine whether an open source component is safe to use. WhiteSource research shows that only 15% to 30% of vulnerabilities are effective; the majority of open source vulnerabilities are not called by the proprietary code. This allows our Analysis team to focus on remediating critical vulnerabilities that are actually impacting their code, saving significant time and allowing them to work through any backlog they may have before each release.
All of our development teams are currently using WhiteSource Renovate. WhiteSource Renovate automatically detects the most recent available versions of open source components so you can keep them up to date. This is important because regularly updating your open source libraries is the easiest way to reduce your overall security risk. Known vulnerabilities are published publicly. If you aren’t updating your components, you are leaving yourself vulnerable to hackers who follow security-related incidents in open source projects to try to exploit known vulnerabilities.
Some of the benefits of using our own software were expected. As a company, security is always top of mind. By giving our developers tools that easily integrate into their day-to-day processes, we’ve shifted security as far left as possible. Furthermore, because security is baked into every stage of the development process, we’re confident that we’re shipping the most secure product possible.
Other benefits were happy side effects. By using our own solution every day as consumers, we’re more intimate with how it performs from a user’s perspective. We’re more in tune with customer feedback, and we really understand where our customers are coming from because we too have experienced the same issue firsthand. This continuous feedback loop is invaluable. This real-life expertise gives our developers a unique insight into our software, which they in turn put back into our product to make it ever better.
We here at WhiteSource truly believe in practicing what we preach. We put our money where our mouth is. We drink our own champagne. You get the idea: We use our software at every stage of the SDLC, which makes our software even better!
By being consumers of our own solution, we have become better developers. Not only are we confident that we are creating more secure and compliant software, but using our own product as extensively as we do gives us a unique insight into WhiteSource and helps us improve our product on a very granular level. But don’t just take our word for it, try it yourself. Drink a glass of our champagne!