FOSS Daily for licensing “hygiene” and vulnerability compliance

Your dentist probably recommended flossing at least twice daily. We recommend that you FOSS at least once a day. 

FOSS Daily is a simple concept: Pay attention to your software – especially your open source components – as a daily habit, rather than on a retrospective cycle like every month, every quarter, or every release. It doesn’t take a lot of time, and you can probably skip a day or two, but long-term neglect can build up into expensive and painful procedures – both technological and dental. FOSS Daily is about small-scale prevention, instead of large-scale remediation.

Software development is always a continuous process. Code is constantly changing in general and the rate of change in dependencies continues to accelerate. Unfortunately, many organizations treat managing open source software as an afterthought, or just a compliance check before releasing and updating code. Without regularly monitoring FOSS components, an organization cannot accurately track the FOSS it is using. You will not have a good understanding of what you’re doing with open source if you don’t make managing it a part of your daily routine.

Developers often look up examples when writing code. There’s a long tradition of developers going to Stack Overflow and similar websites or repositories for code samples. In our experience with software audits, we often find cases where a developer provides a Stack Overflow or similar link to document borrowed code, but rarely do we find any attention paid to what the license of that code might be. This results in code that’s either unlicensed or under an unattractive license (for license compliance).

The default license for Stack Overflow is Creative Commons Attribution-ShareAlike 4.0 International Public License or CC-by-SA 4.0 (earlier versions of CC-by-SA apply to content shared on Stack Overflow at different dates), which is a Copyleft license. Stack Overflow actually tried to change their default to a more permissive license, but that change was blocked by their community.

This is why you need daily attention to the provenance and licensing of open source code. Developers need to get in the daily habit of checking the license for any code snippet before using it in any way. And organizations need to support developers by defining policies for when a snippet is material (e.g., number of lines which may vary by language) and which licenses are acceptable for using a code snippet in otherwise proprietary code. 

This example isn’t meant to scare any developers from using Stack Overflow for inspiration and information – we use it regularly too! The important clarification is that when a developer finds a code snippet with a focus on functionality, they also need to take the relatively small extra step to verify that it is offered under a license acceptable to their organization. If software doesn’t have a license, it’s unlicensed – there is no generic permission.

Organizations that are more attuned to compliance may even prevent the release of products or updates in this situation. Companies are now required to attest to the licensing of their software, typically with a Software Bill of Materials (SBOM). This means a much bigger risk for companies that do not track the provenance and licensing for each FOSS component (or snippet) with continuous daily attention.

Another key area of FOSS compliance that requires daily attention is the identification and mitigation of software vulnerabilities. Hundreds of new vulnerabilities are reported every day and there are also daily updates for vulnerability fixes. Daily triage of vulnerabilities is a key strategy to avoid being overwhelmed by the volume of new vulnerabilities over time. 

Compliance is a continuous process – not a periodic or cyclical process with certain time boundaries – embedding your tooling and policies into your workflows. There will be a steady flow of issues coming up. But that is just something to consider as part of software development and Ci/CD processes. FOSS Daily means that those issues don’t pile up and cause other issues that might block the release of a new software product or product version.

To get started with a FOSS Daily practice, first define your policies: What are your risk management policies for approving a software license and for mitigating software vulnerabilities? What tools do you use? Extending the dental analogy, you can use any kind of floss with good results so long as you pick one that works for your organization and risk management policies.

You have to be able to very quickly identify exceptions to your policy, so that most things can flow through quickly. For an exception you need tools to identify the type of exception, its severity and who is responsible for addressing it.

AboutCode Software Composition Analysis (SCA) tools are modular so that they can be embedded at various points in software development and CI/CD workflows. The key is to efficiently identify changes and exceptions that require your attention. Shifting this left in your workflow helps address potential issues on a daily continuous basis.

When you are writing code, there are linters and other tools to check the syntax of your code, but license information will be in comments or text files, not code. The DeltaCode module of ScanCode Toolkit efficiently scans for changes in licensing information as a complement to other code quality tools. This enables quick identification of any license changes to address them immediately.

For vulnerabilities, you want to track new vulnerabilities that affect your code and also track changes in the status of any vulnerabilities you have already identified. With VulnerableCode, you can automate the reporting for the packages you use and care about and ignore the noise from packages you do not use. And you can see the history of each vulnerability across data sources and time.

We know from psychology that once you adopt a good habit, it becomes a seamless part of your routine. But if you postpone or procrastinate, problems become worse and harder to resolve. 

With the analogy of flossing your teeth daily, nobody wants to go to the dentist for a root canal. The good habit of daily preventive activities helps avoid potential future pain.

The principles behind FOSS Daily are simple. Define your policies. Figure out how to automatically implement those policies and focus daily attention on the exceptions. Run the process every time you make changes with a clear process for exception handling. Deal with those exceptions in a timely manner because they can stack up quickly and develop into much bigger problems than when handled individually.

Daily attention to licensing “hygiene” prevents bigger problems later. It is much easier to ask for help with a small problem or send a specific question, than to wait for all these issues to accumulate and try to resolve them en masse, often at a critical and time-sensitive point in the software development cycle. FOSS Daily is a good habit to support FOSS licensing and vulnerability compliance for your organization.

Share on LinkedIn
Share on Twitter
Share via Email
Share on Reddit

Related posts