What advice do you have for others considering FOSSA?

If you need to automate the tracking of your application dependencies, vulnerabilities, and license expiry, then FOSSA is a good solution. It proactively identifies issues and breaks the CI flow if necessary, ensuring security without manual intervention. I'd rate the solution eight out of ten.

For those seeking to ensure their application is updated with the latest features, FOSSA can be a beneficial add-on. However, it should not replace your existing primary security solutions such as SonarQube or Check Point. I'd rate the solution six out of ten.

Overall, I rate the solution ten out of ten.

I would rate the solution an eight out of ten. I highly recommend the tool to users because its user interface lets us know what we are doing.

I would rate FOSSA a nine out of 10 in terms of efficiency, scaling, and speed. I would rate it a 10 if the documentation to really get into advanced features was more widely available.

There is a temptation to try to insert FOSSA into continuous integration. That was certainly my temptation. To me, that is more work than it ought to be. Sequestering FOSSA into its own job worked out better than trying to insert it into continuous integration. It does not need to be run into a continuous integration. It's not something you need on every commit. That would be an overuse of the tool. Being able to do it as a side project keeps unnecessary failures from happening and it keeps a lot of other things, like unnecessary noise, from happening. However, that's my use case for my particular setup. I can imagine other use cases where having it inside continuous integration would be useful. But for my use case, while that was my first temptation, that was an incorrect approach. Having it as a side job that stands on a schedule, rather than part of the continuous integration, was much more successful. In terms of FOSSA's security and vulnerability management features, I am familiar with them. Our security team uses other tools for those needs at the moment. They've been stuck on them and it has mostly been inertia that has stopped us from changing to or adopting FOSSA more widely. In my opinion, there are some use cases inside of FOSSA, for the security aspect, which are better than our tools. But it is up to the security team to decide if they want to do it. There's been some poking at it over the months, but no serious migration, as of yet. Those parts of FOSSA could be used by us in future, but not at the moment. As for the background and information the solution’s security/vulnerability management features provide on security workflows, it's basically CVE scanning, often before the CVEs get published. So whenever there is a security alert of some sort, it will publish whatever is known based upon all the ongoing, conflicting databases of security scans. It's a helpful "Hey, this bit of software that you're using is known to contain these particular vulnerabilities." The reporting on security and vulnerabilities is pretty good. As I said, I've only used it casually, so I can't really say anything of great value. I haven't looked at it for a while. But I found the reporting, like all their reporting, to be quite clear, understandable, and straightforward. But my exposure to it isn't enough that I can't be more than vague.

With my engineering background, I was supporting legal from the technical side of things in order to get the processes and checks embedded into the development process. The accuracy of the policies and checks was handled by the legal team. I recommend taking a look at, or at least considering, the approach that I took, where I wrote some scripts to automate the steps within a continuous integration pipeline. We've actually open sourced the scripts that we used. They're on GitHub. While the FOSSA CLI tool is fantastic, there tends to be a bit more functionality that you need to build around it that's a little more specific for your organization, and scripting works well for that. Biggest lesson learnt: There's a tool out there that does free, open source license compliance that wants to come in and be part of the software development life cycle early, i.e., as soon as the developer introduces a dependency. Before I found FOSSA, and after my experience with WhiteSource, I thought that I was going to have to write my own solution, which would have been a nightmare because I'm not a lawyer and don't know necessarily how to parse nor understand all these licensed languages. It was a huge undertaking, and I'm one person. Now, since I'm technically not on the engineering team, it's very difficult for me to get engineering resources beyond myself. One of the features that FOSSA has on their roadmap is that they want to provide functionality before a developer ever introduces a dependency, so they can sign into FOSSA, run a search, and find out whether or not that dependency is going to violate policy. Just being able to move those checks earlier into the development process saves a ton of development work and time. I would put FOSSA as a solid eight out of 10. Nothing is perfect. There is always room for improvement. However, they are a fantastic tool and an incredibly responsive organization.

If this is the type of product that you're looking for, they are one of the best products that you can use. The support team has just been amazing, and it helps us to have a great support team from FOSSA. They are there to triage and answer all our questions which come up by using their product. I am not a daily user. I do more of the program management side of setting it up for everyone. I don't actually use it on a day-to-day type of basis. I would rate the solution a 10 out of 10.

My advice would be to understand your software development environments before you try implementing FOSSA. How does the software move through your system? How does it go from being source code to production software? Through that, you can identify the point where you want to place FOSSA. We did an evaluation and used our software delivery pipeline to identify what should be scanned, and that helped to increase acceptance. Others will understand better, once they know their software ecosystem's final, production quality software that consumers are going to use or ingest, that that is what FOSSA is best at doing. If they understand those connection points then they will have a better integration. Knowing what FOSSA can do, where to put it, was the biggest decision that we had to make and the hardest decision we had to make. FOSSA simplified it with their CLI app. The solution helps me work with both legal teams and DevOps, in a way. However, I still haven't been able to roll out FOSSA for general use by everybody. I don't know how useful it would be for the legal teams because they've already worked with me in establishing policies and then left it with my department to make decisions based on those policies. If there's ever a question about things, we have offline discussions. But they typically don't get into FOSSA because there's not much of an interface there for them, per se. I could see creating an interface that's more targeted at the legal side of things, but I don't feel that is necessary in our situation because I tend to handle the issues that might arise as legal questions. If I need to go further, I will talk to them. I might share some information from FOSSA, but I don't direct them to FOSSA because there's really nothing that I can show them that's going to give them what they need. The biggest lesson I have learned from using FOSSA is having patience to understand what the teams are using and why they're using it. This is all in the context of the fact that we went from being a company with no open source program office, and a very light policy touch on what was allowed and what wasn't allowed. So it has really been about patience in working with those teams, understanding their needs and FOSSA as a tool they're going to have to work to accept. But it was also important to listen to them so that I could make changes to the way that I had the FOSSA implementation done, to simplify their work. Asking them to do something new was a big ask in their already busy days, so making it as simple as possible was something that I had to figure out and patience is what really made that possible. When I initially tried to roll out FOSSA, I received a lot of pushback from what I would say is the "old guard" at my company. FOSSA was a company that had only been around for about eight to 10 months at the time. They were essentially a startup. Their CEO, Kevin, is a very brilliant guy. He has a finger on the pulse of the future of open source. Some of their actions and what they've done since I started working with them show that they really understand it. With the old guard of my company, I ran into ageism, where they said, This is a very young company with a bunch of young people. How are they going to know what to do in this particular industry?" That is something that other companies might run into: "Why should we go with a startup over something that's established, like a Black Duck?" The reason you should is because FOSSA is a hungry company, wanting to do good by their customers, and it's a company that cares about what their customers' needs are. Everybody that I had talked to at trade shows about FOSSA was happy with them as well, it seemed. They had their gripes and their complaints, just like I do, about functionality within the software. But overall, it simplifies our jobs, and others recognize this. Other companies that are trying to make a decision should be aware they may run into these kinds of issues. FOSSA is now just over three years old. It's still establishing itself against bigger companies. When Synopsis announced that they had acquired Black Duck, I went and looked at what they did as a company - they were into printed circuit boards, hardware on circuit boards, and hardware security. To me, that's a company that has no idea what open source software truly is. They might use it, but do they really have an in-depth understanding of it and the security around it? Just because they did security for PCBs doesn't mean that security in software was going to be a natural fit for them, and I still don't think it is. Some people stick with what they know, and are unwilling to look at something new. Those people should really give FOSSA a chance because, as a hungry company, FOSSA is going to be willing to work more with companies that adopt them, unlike larger companies. FOSSA is young - they're in tune with what's going on with modern software. Evaluating the newer option was the right choice for us, and for me. Overall, it's a great product. It's really well organized in its interface and it is targeted towards a manager of an open source program office. Other products I looked at seemed to be more targeted at developer operations. And because I wasn't specifically trying to be DevOps, FOSSA really worked. It really fits in with my workflow.

It's easy to use, it's easy to maintain, and it saves you time on your open-source license compliance work. I felt like the solution was very tailored for open-source license compliance with their license. I would rate FOSSA a nine out of ten. There were a few little things that could be improved, but overall for my use case, it was great.

Focus on those applications that pose licensing risks. I don't believe that one needs to use FOSSA to scan everything. You need to use FOSSA to scan products that you distribute to third-parties. The biggest lesson I have learned using the solution is that command-line integration is the most important part of a scan tool. We don't really have "users" using it. There's really only one person who does most of the work around FOSSA and everything is automated. Very rarely does somebody go into the tool and do anything, but we have many apps that are scanned with FOSSA. The one person who goes into it is one of the mobile build engineers and he is responsible for the mobile build process, which includes FOSSA scanning. We do not use FOSSA's security or vulnerability management features yet. We want to. We know that that was recently released, but we haven't enabled them on our internal build yet. There's opportunity for the solution to grow. There are things that it needs to do that it doesn't yet do. There are things it does that I'm satisfied with. I can't give it a 10 because there's opportunity to grow, so this is really less a measure of the product and more a measure of my expectations for the product. I'll give it a favorable eight, because it does what I need it to do, but I need it to do more as well.

With the rapid growth of the consumption of open-source in development, it was no longer feasible for attorneys to manually review every incoming component on an individual case by case basis. Having a tool to automate the review, both from a legal, but also a security perspective, and provide near-immediate feedback to the developer was critical to have. My advice would be that if you have a very large volume of open-source that you can apply clear and consistent policies to or you currently do that in a manual process, that something like this is absolutely worth every dollar to be able to keep your teams moving quickly and efficiently. Implementing something like this is definitely worthwhile if someone is on the fence with respect to spending the money to look at the open-source components, both from a license and security perspective in a fast and efficient manner. The biggest lesson I learned from this solution is that there's a much larger volume of open-source components that might be in your environment that you may not be aware of given the comprehensiveness of FOSSA's scanning of both top-level components and transitive dependencies. You'll learn that there's an incredibly large number of components in your applications. I would rate it an eight out of ten.