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
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 10
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.
Data Privacy Officer at a healthcare company with 51-200 employees
Real User
May 16, 2021
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
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
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
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.
Sr. Director of Open Source at a comms service provider with 10,001+ employees
Real User
Jun 2, 2020
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.
FOSSA automates license compliance and manages dependencies in development environments, offering efficient policy engines and integration with build pipelines, valuable to legal and DevOps teams.FOSSA offers deep dependency scanning, seamless compatibility with developer tools, and integrates smoothly into CI/CD pipelines. It automates license checks to save resources and maintains policy compliance. It helps in identifying open-source licensing issues and tracks dependencies to prevent...
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.