In our current project, we are using FOSSA as part of our CI/CD pipeline. It is used to scan our projects to ensure that our dependencies are up to date and do not introduce vulnerabilities to our code.
Senior Software Engineer at a manufacturing company with 10,001+ employees
Real User
Top 20
2024-10-24T14:28:00Z
Oct 24, 2024
I have worked with FOSSA primarily to manage the dependencies in our projects. For example, if I take a Spring Boot application, FOSSA helps in identifying mismatches or unsupported dependencies that arise due to version updates of Java or Spring Boot. It provides suggestions for upgrading specific modules to maintain compatibility. The tool focuses on ensuring the versions of dependencies are in sync with the current versions of the application.
Head of Open Source Engineering and Technology at a financial services firm with 10,001+ employees
Real User
Top 20
2024-09-11T16:39:38Z
Sep 11, 2024
FOSSA is a software composition analysis tool that can scan applications to determine their open-source components. The solution can be used for record-keeping, license compliance, vulnerability detection, and obsolescence management. In some cases, it is used for compliance because the federal government, PCI, and certain regulatory agencies require software bills of material.
I lead the legal team at my organization, and we use FOSSA largely in partnership with our engineering teams. We use FOSSA for open-source software licensing scans and diligence. We are using its latest enterprise version.
Our major use case is to do open source license compliance. Puppet Enterprise consists of about 90 open source packages under constant development. And it also has some components which are not open source. When we release Puppet Enterprise, we have to make sure that anything that we're relying on is something that we are allowed to use, in an open source sense. It does do security scanning, which is something that we're interested in and want to do, but we've only been using FOSSA casually for that. I am the only person really running the FOSSA jobs. I have a FOSSA job that runs daily, that scans all of our important repositories and reports back to me and the release engineering team about what it found. When we go to do a release, we run a report from FOSSA which contains all of the open source licenses in our product and we do a rescan of that to make sure that there aren't any flagged licenses inside of our product. That's our use case. None of the actual engineers are worried about it. Only when something gets flagged do I contact them and say, "Hey, this license isn't working for us, so we need to find something else." FOSSA is a cloud project and it contains a CLI component that's open source.
Sr. Security Architect at a computer software company with 1,001-5,000 employees
Real User
2020-09-27T04:10:00Z
Sep 27, 2020
FOSSA provides a command line interface tool, and we always use the latest version of that. It gets pulled down automatically by some scripts that I've written, so we will always pull down its latest version. We're using it primarily for the free, open source license compliance portion of it. Those scripts that I've built have the ability to be able to fail builds on pull request checks, though we haven't started enforcing that yet. Therefore, we're really primarily using FOSSA as a dependency inventory tool, then our legal team can also review and give feedback to the teams about the licenses that they're using. In the future though, we are planning on leveraging FOSSA for that policy enforcement piece as well.
Program Manager at a consumer goods company with 10,001+ employees
Real User
2020-09-23T06:10:00Z
Sep 23, 2020
We use it to scan all of our open source projects, including all of our internal projects that people use. We are about to roll it out to the whole company. Currently, we're only using it for open source projects, making sure people are scanning before they get the project approved.
Manager of Open Source Program Office at a financial services firm with 5,001-10,000 employees
Real User
2020-09-15T11:13:00Z
Sep 15, 2020
We use it to scan for all licenses, to identify the open source licenses that are found, to identify licenses that are unknown or unrecognized so that we can deal with those, and we use it to make sure that our client-facing apps are compliant with open source licensing requirements.
Our primary use case was for the license compliance. We were doing all the open-source scanning in our CI build using FOSSA. So we would use it, have a step where FOSSA would be installed, and it would scan all the open-source libraries that were being used and then report back on what those licenses were. Then that would match up with policies that we had preset in the FOSSA UI and let us know if there are any license violations with our use of open-source.
The primary use case for FOSSA is that when we build mobile applications — we have a few dozen mobile applications that we build — the build script calls FOSSA automatically and determines through the FOSSA scan what licenses are being used in the dependencies, and it determines if they comply with our policies. If they don't, it notifies that there's a problem. If they do, it generates information that we turn into a report that we then use to disclose what licenses we're using in our product. There's a secondary use case, which isn't about mobile apps but about looking at code in general and running it through FOSSA to see what it can find, but that's a very rare occurrence. Most of the time we're just automatically scanning mobile apps
Our use cases are for handling incoming open-source software for high speed or agile development that our teams are doing. We also use it for looking at security vulnerabilities in real-time as they're doing their daily builds. It helps to compile distribution acknowledgments or the open-source acknowledgments that need to go out with any distributions.
Up to 90% of any piece of software is from open source, creating countless dependencies and areas of risk to manage. FOSSA is the most reliable automated policy engine for legal teams to maintain license compliance, security to fix vulnerabilities, and engineering to improve code quality across the entire software supply chain. As the only developer-native open source management platform, FOSSA fully integrates with your existing CI/CD pipeline to provide complete visibility and context...
In our current project, we are using FOSSA as part of our CI/CD pipeline. It is used to scan our projects to ensure that our dependencies are up to date and do not introduce vulnerabilities to our code.
I have worked with FOSSA primarily to manage the dependencies in our projects. For example, if I take a Spring Boot application, FOSSA helps in identifying mismatches or unsupported dependencies that arise due to version updates of Java or Spring Boot. It provides suggestions for upgrading specific modules to maintain compatibility. The tool focuses on ensuring the versions of dependencies are in sync with the current versions of the application.
FOSSA is a software composition analysis tool that can scan applications to determine their open-source components. The solution can be used for record-keeping, license compliance, vulnerability detection, and obsolescence management. In some cases, it is used for compliance because the federal government, PCI, and certain regulatory agencies require software bills of material.
We use the solution for the security compliance and licensing of open-source components.
I lead the legal team at my organization, and we use FOSSA largely in partnership with our engineering teams. We use FOSSA for open-source software licensing scans and diligence. We are using its latest enterprise version.
Our major use case is to do open source license compliance. Puppet Enterprise consists of about 90 open source packages under constant development. And it also has some components which are not open source. When we release Puppet Enterprise, we have to make sure that anything that we're relying on is something that we are allowed to use, in an open source sense. It does do security scanning, which is something that we're interested in and want to do, but we've only been using FOSSA casually for that. I am the only person really running the FOSSA jobs. I have a FOSSA job that runs daily, that scans all of our important repositories and reports back to me and the release engineering team about what it found. When we go to do a release, we run a report from FOSSA which contains all of the open source licenses in our product and we do a rescan of that to make sure that there aren't any flagged licenses inside of our product. That's our use case. None of the actual engineers are worried about it. Only when something gets flagged do I contact them and say, "Hey, this license isn't working for us, so we need to find something else." FOSSA is a cloud project and it contains a CLI component that's open source.
FOSSA provides a command line interface tool, and we always use the latest version of that. It gets pulled down automatically by some scripts that I've written, so we will always pull down its latest version. We're using it primarily for the free, open source license compliance portion of it. Those scripts that I've built have the ability to be able to fail builds on pull request checks, though we haven't started enforcing that yet. Therefore, we're really primarily using FOSSA as a dependency inventory tool, then our legal team can also review and give feedback to the teams about the licenses that they're using. In the future though, we are planning on leveraging FOSSA for that policy enforcement piece as well.
We use it to scan all of our open source projects, including all of our internal projects that people use. We are about to roll it out to the whole company. Currently, we're only using it for open source projects, making sure people are scanning before they get the project approved.
We use it to scan for all licenses, to identify the open source licenses that are found, to identify licenses that are unknown or unrecognized so that we can deal with those, and we use it to make sure that our client-facing apps are compliant with open source licensing requirements.
Our primary use case was for the license compliance. We were doing all the open-source scanning in our CI build using FOSSA. So we would use it, have a step where FOSSA would be installed, and it would scan all the open-source libraries that were being used and then report back on what those licenses were. Then that would match up with policies that we had preset in the FOSSA UI and let us know if there are any license violations with our use of open-source.
The primary use case for FOSSA is that when we build mobile applications — we have a few dozen mobile applications that we build — the build script calls FOSSA automatically and determines through the FOSSA scan what licenses are being used in the dependencies, and it determines if they comply with our policies. If they don't, it notifies that there's a problem. If they do, it generates information that we turn into a report that we then use to disclose what licenses we're using in our product. There's a secondary use case, which isn't about mobile apps but about looking at code in general and running it through FOSSA to see what it can find, but that's a very rare occurrence. Most of the time we're just automatically scanning mobile apps
Our use cases are for handling incoming open-source software for high speed or agile development that our teams are doing. We also use it for looking at security vulnerabilities in real-time as they're doing their daily builds. It helps to compile distribution acknowledgments or the open-source acknowledgments that need to go out with any distributions.