Sonatype Lifecycle Reviews

We manage the overall software development security organization, encompassing assistance to all developers across our organization worldwide. Our 10,000 developers help identify vulnerabilities in their code. We use Fortify Static Code Analyzer to explore methods to expedite vulnerability detection and remediation through a self-service pipeline.

Initially, we utilized Just Cloud, but subsequently, we developed our on-premises tools over the ensuing year. This resulted in substantial cost savings, as on-premises security solutions are generally more economical than their cloud-based counterparts.

Fortify Software Security Center, often abbreviated as SSC, offers both an on-premises and cloud-based version. The cloud-based version is called Fortify On Demand or FOD. FOD is a popular choice for organizations that want a flexible and scalable solution, while the on-premises version is preferred by organizations that require more control over their security infrastructure. OpenText, the vendor of Fortify, offers various consumption models for its solutions. Users can pay per scan or opt for an annual subscription with unlimited scans. However, annual subscriptions can be expensive, with some organizations paying millions of dollars per year. Using the on-premises tools can provide significant cost savings compared to cloud-based solutions, but it also requires a dedicated team of IT professionals to manage and maintain the infrastructure. If an organization lacks the resources to manage on-premises tools, FOD is often the most affordable and robust solution available. In comparison, competitors like Synopsys and Checkmarx typically charge even more for their cloud-based solutions.

The Fortify portal is well-suited for managing and tracking risks associated with the open-source components used in our software projects. The increasing availability of open-source options has been beneficial. OpenText's acquisition of Debricked a couple of years ago has further enhanced its capabilities in this domain. They continue to utilize Sonatype within the FOD, providing customers with a choice. For existing Sonatype customers who have been using the tool as Micro Focus' and OpenText's partner for FOD for many years, continuing with Sonatype remains a viable option. However, for new users or those seeking an alternative to Sonatype, Debricked, now OpenText's open-source security tool, is an excellent choice, seamlessly integrated into FOD.

Utilizing Fortify to identify vulnerabilities has become remarkably effortless. Based on my experience, I've observed a significant increase in user satisfaction with the tool. Over the years, we've acquired several companies that initially held negative perceptions of Fortify, stemming from its previous reputation as a cumbersome and resource-intensive tool. However, with the introduction of FOD and the enhanced capabilities of the on-premises tools, we've witnessed a dramatic shift. The availability of lightweight on-premises tools, coupled with seamless IDE plugins for Visual Studio, Eclipse, and other intelligent IDEs, alongside integrations into Azure and Jenkins pipelines, has significantly empowered users to conduct self-service vulnerability scans in minutes, a stark contrast to the time-consuming hours it previously required.

Fortify enhances our vulnerability remediation efforts by providing more reliable results. Secure Code Warrior integration plays a significant role by providing developers with access to secure coding training, which I believe positions them better to identify and resolve issues promptly. Many companies lack access to this level of guidance and often rely on standard verbiage. I appreciate that users can leverage Secure Code Warrior's guidance for their Fortify findings. This capability is not offered by any other company in the space. Additionally, they have recently partnered with MAB to offer automated code remediation solutions. Automated code remediation means that if I'm a developer and Fortify identifies a vulnerability, instead of manually fixing it, MAB, their partner, can automatically resolve the issue by providing a prebuilt fix and incorporating it into our build pipeline.

Fortify enables our developers to build secure code from the beginning. I can speak with confidence that without Fortify, we wouldn't have fixed thousands of vulnerabilities, and it is helping to streamline that process for developers, whereas Many other security teams rely on traditional PAN testers, Fortify has given our developers the confidence to be able to find, fix, and remediate issues, and a fully self-service mechanism that few other companies have.

Both Fortify and Sonatype have excellent integrations with compliance frameworks such as GDPR, PCI, and DSS, providing comprehensive reporting capabilities that help us meet regulatory requirements. These integrations enable us to stay abreast of evolving regulatory requirements and ensure that our vendor partners promptly address any changes. For example, when the OWASP categories were updated two years ago, both Fortify and Sonatype quickly released support for the updated categories, allowing us to seamlessly update our reporting without delay.

Fortify mitigates risk exposure in applications by identifying vulnerabilities and weaknesses. It pinpoints all the issues that developers need to address and provides comprehensive guidance for remediation.

It provides robust details about the issues, along with comprehensive insights into what needs to be fixed. The ability to see all of the different versions in Sonatype results has been particularly helpful as an indicator.

Fortify's expansion into shift-left security for cloud-native applications has been an exciting development. I wasn't expecting them to venture into this area, but I'm pleasantly surprised by their progress. It appears that they are well-positioned to gain significant market share.

Fortify has helped free up our staff time for other projects by improving our automation capabilities. As a result, we have been able to significantly reduce our turnaround time for remediation tasks. This has allowed our developers to focus on more strategic initiatives, such as automation and engineering, instead of being bogged down with manual remediation work. We have saved over $40 million in headcount expenses by automating these tasks. It would have taken over 100 years to fix all of these issues manually, using our previous processes. In other words, Fortify has automated millions of hours of work, equivalent to the work of hundreds of thousands of people over decades. This is one of the most significant automation projects we have ever undertaken.

Identifying vulnerabilities using Fortify early in the software development life cycle has resulted in significant cost savings compared to discovering them later on. Fortify has enabled us to detect and remediate these types of issues at the beginning of the SDLC. As a result, we can prevent potential problems from reaching the production stage.

Fortify integrates seamlessly with other solutions, which is a significant advantage in our opinion. As I mentioned earlier, Synopsys has struggled with third-party integrations. In contrast, Fortify has taken the lead in collaborating with Secure Code Warrior, reconciled, and MOB to facilitate these integrations. This has allowed us to establish an ecosystem of solutions from various providers that are at the forefront of innovation.

We have integrated Fortify with Sonatype, Secure Code Warrior, and MOB. The integrations take no more than a few hours.

The Software Security Center, which is often overlooked, stands out as the most effective feature. This on-premises portal, included with their primary SaaS offering, streamlines the process of triaging our results. With thousands of daily active users, the Software Security Center serves as a centralized platform, consolidating results from various tools, including Sonatype, WebInspect's DAST results, and Pen Test findings from our internal team. This unified view eliminates the need for developers to log into multiple portals to access code vulnerabilities, open-source issues, web app scans, and Pen Test results. Instead, they can access everything they need from a single, convenient location.

Secure Code Warrior is an invaluable integration and partnership for us. Fortify consistently collaborates with top-tier companies to deliver cutting-edge solutions. For instance, if a developer encounters a common code vulnerability, such as a path manipulation vulnerability in their Java website, and is unsure of how to resolve it, Fortify provides some guidance and standard response protocols. However, for more in-depth information and assistance, they direct us to Secure Code Warrior. Upon providing information on the vulnerability type and language, Secure Code Warrior offers tailored training courses, such as how to fix path manipulations in Java-based applications. This remediation technique, which is unmatched by any other provider, has proven to be incredibly effective.

Fortify's software security center needs a design refresh. It has maintained the same design for the entirety of our five years of use, making it feel outdated compared to its FOD portal, which receives regular bi-monthly updates. This area is a prime candidate for improvement in the future.

Fortify needs to move to a more frequent release cycle Currently, they only release two updates per year, which is considerably slower than their peers, so I would very much like to see that improve.

I have been using Fortify Static Code Analyzer for five years.

Fortify Static Code Analyzer stability has improved and I would give it a ten out of ten.

The scalability of the Fortify Static Code Analyzer is a ten out of ten.

We have a weekly call with their technical support team. Their service has improved dramatically since they allocated a dedicated premium support team to us. We now have a point person who works closely with us to address our concerns.

The support itself is very good. They are always responsive and present, and they're willing to work with us on challenges. I would give them a ten out of ten for their responsiveness and presence. However, for issues that require product enhancement, I would give them a lower score. These issues often require us to wait for someone on their product team to implement something, which can be frustrating.

Positive

We have previously used Synopsys, Coverity, and Checkmarx. Fortify stands out for its comprehensive language support, which is a major reason for our satisfaction with their product. For example, Fortify is the only tool that supports mainframes and COBOL. It's encouraging to see their turnaround in this area, and they now support over 30 languages. Checkmarx excels in the design simplicity of its open-source integration in FOD, a new feature, and its cloud-native capability. Checkmarx boasts a sleek user interface that is highly intuitive for new users, while Fortify may require some time to get accustomed to. Coverity used to be a top contender, known for its accuracy and effectiveness. However, their quality and execution speed significantly deteriorated following the Synopsys acquisition. Synopsys has shifted some of its engineers to other projects, negatively impacting the quality of its Coverity product. Despite these drawbacks, Checkmarx remains a strong competitor to Fortify in terms of quality. While Synopsys invests heavily in marketing, its product no longer meets the standards of a robust enterprise tool.

Initial deployment of the SaaS SOD solution was straightforward to get started with. However, on-premises deployment took a bit longer. It took us several months to get that piece up and running.

The initial deployment required seven people.

We did work with a third party to help us facilitate the buildout. That third party was Saltworks Security.

Through our ongoing partnership with Fortify and their commitment to working closely with us, we have experienced a significant return on investment, with benefits ranging from ten to twenty times our initial investment. Additionally, the continuous introduction of new features over the years has further reinforced our assessment of Fortify's value.

From our standpoint, we are significantly better off with Fortify due to the favorable pricing we secured five years ago. I'm unable to comment on their current pricing; however, I am aware that switching to a different vendor like Checkmarx would result in considerably higher costs. It appears that we're paying a premium for the robustness of their design rather than being able to benefit from the pricing that was previously negotiated.

I would rate Fortify Static Code Analyzer ten out of ten.

It is incumbent upon any security leader to incorporate automation and self-service into any initiative, regardless of whether it pertains to identity and access management or software development security. The goal is to simplify security and make it an enabler rather than a hindrance. Organizations should strive to provide cybersecurity controls as intuitive solutions, not as complex configurations that require extensive effort to understand and implement.

We have close to 20 people who support Fortify full-time.

I recommend doing a POC and confirming that the automated integrations work for the organization before implementation.

We use Fortify SCA or SAST for scanning the source code, and we use Sonatype Nexus to scan libraries for any vulnerabilities. We get secure code and libraries by combining these two solutions. If we find any issues, we can fix them.

We use Fortify SAST to scan our code. It is used for the static code and not the running code. It finds vulnerabilities, and it finds bad practices. If you are using something that can be exploited in the code, it highlights that and gives you recommendations on that. It gives you ideas on how to fix that.

We have a more secure code because it is based on top security standards. Before we moved to Fortify SAST, we already had code running in production. When we moved to Fortify SAST, we had to rescan our code running in production. We got more and more vulnerabilities, which made people upset, but overall, our security was enhanced. It also enhanced the knowledge of our developers. Our developers are learning more. Many developers were frustrated in the beginning because there were many vulnerabilities, but as time went on, they liked its features. They find it straightforward now. They read about it, and they can fix their code easily. Without any back-and-forth communication, they can find the line, the recommendation, and what to do about it in one place. That is awesome.

Fortify Software Security Center gives a good overview of how the application is implemented, but it is not a 360-degree view. Sometimes we have false positives, and sometimes, it does not catch the design flows. It will mark something as vulnerable because it does not have the full picture. The highlighted code might be a part of another module, so it cannot see the full picture, but it is a very good tool. It is better than the ones we had before.

I have not yet used Fortify Software Security Center for managing and tracking risks associated with the open-source components used in our software project. We recently started to use Fortify SAST and are still exploring and discovering things. We usually do that through Sonatype Nexus, but I have seen it catching vulnerabilities. Some users have scanned the library by mistake, and I have seen it catching vulnerable code in the library. It points out why we wrote the code this way, and the code should have been that way. If there is a variable that has a sensitive name, such as a key, password, or something else, it catches that. After we have integrated it with Sonatype, we will have more exposure, but we are not yet at that stage.

I really like Fortify Software Security Center. We can scan the code and push the results. I can also see all the applications. I know the portfolio of the applications that we have. I can see all the information about the organizations, the code, and the developers in one spot. It is good for the management and also for the development teams. If their supervisors want to know the security status of their applications, they can go there straight away and check that information. It is very good in this aspect.

Fortify SAST has helped in the remediation of potential vulnerabilities by using accurate and reliable results. I like that they use standards such as OWASP Top 10 or SANS Top 25. They are very good at this. When it finds any vulnerabilities, it shows you by the rank. You can filter by so many standards. It gives you a description of the vulnerability as well as recommendations on how to fix it. It also gives you some references if you want to read more. It is very good.

Fortify SAST has helped a lot to enable developers to build secure code from the start. We have many developers. They have the development skills, but they do not have security skills. Now, there is something that tells them how to write the code properly. For instance, they use a function, and then they get the recommendation to use another function. They do not know the other function. They go ahead and use it, and the code still runs as before, but it is safer. With time, people avoid these issues. It is like a spelling checker. You get recommendations while writing the code.

Fortify and Sonatype solutions help to maintain compliance with applicable regulations. Fortify SAST is built on top of very high standards such as OWASP Top 10, SANS Top 25, PCI DSS, etc. These are very repeatable security standards. It includes over a thousand vulnerability categories. It covers a lot of vulnerabilities.

Fortify SAST helps us reduce our risk exposure on applications through the discovery of vulnerabilities and weaknesses. They have something called rulepacks that are the guidelines. There are rulepacks for different languages. They are the security standards that the code will follow. These rulepacks are updated frequently by the Fortify team themselves, and we just have to feed them into Fortify Software Security Center so that it has updated information about vulnerabilities, and it can discover more. The more you discover and fix, the more secure and resilient code you will have.

Fortify SAST provides real-time feedback on security issues. When you scan, you get the results instantly. Sometimes, for certain code languages, it takes a little more time to scan, which can be frustrating, but it provides real-time feedback. You get a small description, and you also have the details. There is one tab for recommendations, and there is also a tab for references.

We recently had this activity where we wanted to integrate the tool with a pipeline. We are using Azure DevOps, and we managed to integrate that. It was straightforward. You get a plugin or an extension, and the code is pushed and scanned, and you get the results. It is straightforward. I can see it functional for such deployments. We are ready for the cloud and automation, but we are still in the testing phase.

Fortify SAST has helped free up our staff for other projects or tasks. Because it is very informative and clear, we have a lot fewer issues for which people come back to us. They come back to us if they think it is a false positive or if they need a waiver because they cannot fix it due to some limitations, but in the majority of cases, they can control and learn, and they can do it on their own. It helped us a lot in this aspect, but I do not have the metrics. We have been using it only for a few months, and we have a shortage of people. It has saved the communication time that we were spending on emails and reporting. We now have less of that. We all go to one place. Instead of sending me an email or having a phone call, developers now go to Fortify Software Security Center and put in what they think. For example, they will say that it is a false positive because of this and that. They will send it to me, and I will go to Fortify Software Security Center. I will read it and review it, and if I find it okay, I will give the go-ahead to get rid of it. Otherwise, we would need more discussion. It improves communication big time for me.

I like Fortify Software Security Center or Fortify SSC. This tool is installed on each developer's machine, but Fortify Software Security Center combines everything. We can meet there as security professionals and developers. The developers scan their code and publish the results there. We can then look at them from a security perspective and see whether they fixed the issues. We can agree on whether something is a false positive and make decisions. I like Fortify Software Security Center. It was not the way we had before. We used to have another tool, and it did not have this feature. I also like the fact that it supports many languages. It supports more than 30 languages. It covers a lot of what we do. Its configuration is a little bit tricky, but after you configure it, it is intuitive.

I also like the integration capability. It can integrate with many IDEs, such as IntelliJ, Eclipse, VS Code, etc. It integrates with all the main ones. It also can integrate with Nexus. It can integrate with Secure Code and Azure DevOps. This is really good to have something that can work with many vendors. It gives you versatility and flexibility.

We have integrated it with Azure DevOps for the pipeline, and we have integrated it with Secure Code. It is not a major integration. We have a plan to integrate it with Sonatype. I like to have everything in one place. All the integrations happen in the IDEs. We have people using Eclipse, IntelliJ, Visual Studio, VS Code, etc. We have integrated it with all the IDEs that we have here. The integration with IDEs was straightforward. You just install the plugin, add it to the IDE, and add your configuration. For Azure DevOps, we needed to add the binary, and it took a day or two because people were not familiar with it. For Secure Code, it was straightforward again. It is not hard to integrate. Its integration is easy.

One downside to it is that it is costly. I can see it only for enterprises. I cannot see it for small businesses or for individual use.

The configuration part is a little bit tricky. There is a learning curve there because it has multiple components. If someone has used another type of scanner, they would not think of the configuration intuitively. The configuration part can be better. Installation is straightforward, but the configuration can be better. It can be improved.

There is a learning curve. Before we started using this tool, I did a lot of sessions with the vendors themselves to give an overview to the people. I also did a small documentation on how to install it because there are many components here and there. You need to understand how everything is put together. They can integrate it or make it a simpler process.

During the short experience that we have had with it, we have noticed that some of the languages such as JavaScript and TypeScript consume high resources. They take a longer time to scan. Memory consumption is also very high for those languages. We are working with Fortify to find ways to optimize the scan. I noticed this with these types of languages. By nature, they take time.

It can be tricky if you want to exclude some files from scanning. For instance, if you do not want to scan and push testing files to Fortify Software Security Center, that is tricky with some IDEs, such as IntelliJ. We found that there is an Exclude feature that is not working. We reported that to them for future fixing. It needs some work on the plugins to make them consistent across IDEs and make them easier.

For integration with IDEs, they have so many plugins. For example, they have something called security analysis, and they have something called remediation. As a user, I would love to have them as one. Why should we have two plugins in the same IDE? Just give me one plugin that I can hook to the tool and use it. This is one thing. Some of the features in these plugins also need more testing. They are not consistent across all the IDEs. From what I saw, there are different options in these tools. For example, if you install it with IntelliJ, it will be different from VS Code. Some options are different, or one tool has more options than others. They can invest more in making them consistent.

We are a big company. We have different organizations. For our organization, we started using this solution this year, but other organizations have been using it for two years.

From what I have seen so far, it is very stable. It is a browser-based solution. You just log in to the website and see all your applications. From your machine, you can just push, and it will be published there. You click a scan, and your results will be in Fortify Software Security Center. It is straightforward and easy to use.

It is being used at multiple locations and in multiple buildings. The security requirements are very high in our environment, so not everything will work as you expect it because not everything is open. We struggle a bit, but it is required. We have around 60 people who use Fortify SAST.

We have not tested it yet, but they have something called ScanCentral. Currently, developers scan the code on their machines, and then they push it to Fortify Software Security Center. ScanCentral is a feature that we will start to experiment with soon where we offload the scan to a server. It will not utilize developers' resources. It will just initiate a scan, and it will use another system to scan. I have heard that you can have many of them implemented. I have not experienced it yet, but it seems like a cool feature to free the resources for developers because they need to deploy, compile, and fix. If it frees up their resources, it will be good.

I am very satisfied with their support. They are very nice people, and they are very helpful. I would rate their support a ten out of ten.

Positive

We were using IBM Appscan. We switched because of limitations and support. We found that developers were able to tweak it and play with it. They could play with the results. Its support had also ended, and it supported fewer languages. There were multiple reasons, and this is why we had to switch to something else.

I needed their help with the setup. It was mainly because our environment is a little bit strict. It is not the easiest environment to work in. It is not only applicable to Fortify; it is applicable to many other vendors, but with their help and support, it was doable. We have a very restricted environment. If you read a document and follow it, it should work, but because of our environment, we need to open this or that. We had access issues at the beginning, but once we resolved them, it was fine.

It took weeks because of the access issues that we had. We had to reach out to the vendor and ask them why it is behaving this way.

In terms of maintenance, we need to update rulepacks. We need to take care of the licenses. In the beginning, we used licenses from a neighbor until we got ours. We need to take care of the routine activities related to licensing and patching. If we find any vulnerability with the tool itself, we need to do patching. It is like any other tool.

We had people from the cloud team. We had people from the administration team. We had people from the database team. Overall, we had four or five people involved but not always together. When you configure the database, you will be with the database team. When you configure the cloud, you will be with the cloud team.

It is too early to say whether we have seen an ROI, but we have had a great communication and learning experience.

Identifying vulnerabilities using Fortify SAST early in the development lifecycle saves costs versus discovering vulnerabilities later in the software development lifecycle (SDLC). If you discover a vulnerability early, it is helpful. For instance, if you are writing Java code and you know that there is a limitation or vulnerability in that version of Java, it helps to plan your journey of development earlier. You get to know that your server does not support this version of Java. It helps you make decisions earlier in the process. Time is money. The earlier you handle things, the better it is.

There is a licensing fee, and if you bring them to the company and you want them to do the installation and the implementation in the beginning, there is a separate cost. Similarly, if you want consultation or training, there is a separate cost.

I see it as suitable only for enterprises. I do not see it suitable for a small business or individual use. In the future, if they have other versions for smaller organizations or individuals who want to install it on their machines and use it, it would be good.

To someone whose company is still using manual methods to find vulnerabilities, I would say that when you automate it, you control it. You give more power to people, especially from a security point of view.

I would recommend Fortify SAST if you have money and multiple teams. It is useful for multiple teams, but for a small company with one team of two to three people, I would not recommend it. If you have a big community with many organizations and many development teams, it is worth it.

Overall, I would rate Fortify SAST an eight out of ten.

We use Fortify SCA or SAST for scanning the source code, and we use Sonatype Nexus to scan libraries for any vulnerabilities. We get secure code and libraries by combining these two solutions. If we find any issues, we can fix them.

We use Fortify SAST to scan our code. It is used for the static code and not the running code. It finds vulnerabilities, and it finds bad practices. If you are using something that can be exploited in the code, it highlights that and gives you recommendations on that. It gives you ideas on how to fix that.

We have a more secure code because it is based on top security standards. Before we moved to Fortify SAST, we already had code running in production. When we moved to Fortify SAST, we had to rescan our code running in production. We got more and more vulnerabilities, which made people upset, but overall, our security was enhanced. It also enhanced the knowledge of our developers. Our developers are learning more. Many developers were frustrated in the beginning because there were many vulnerabilities, but as time went on, they liked its features. They find it straightforward now. They read about it, and they can fix their code easily. Without any back-and-forth communication, they can find the line, the recommendation, and what to do about it in one place. That is awesome.

Fortify Software Security Center gives a good overview of how the application is implemented, but it is not a 360-degree view. Sometimes we have false positives, and sometimes, it does not catch the design flows. It will mark something as vulnerable because it does not have the full picture. The highlighted code might be a part of another module, so it cannot see the full picture, but it is a very good tool. It is better than the ones we had before.

I have not yet used Fortify Software Security Center for managing and tracking risks associated with the open-source components used in our software project. We recently started to use Fortify SAST and are still exploring and discovering things. We usually do that through Sonatype Nexus, but I have seen it catching vulnerabilities. Some users have scanned the library by mistake, and I have seen it catching vulnerable code in the library. It points out why we wrote the code this way, and the code should have been that way. If there is a variable that has a sensitive name, such as a key, password, or something else, it catches that. After we have integrated it with Sonatype, we will have more exposure, but we are not yet at that stage.

I really like Fortify Software Security Center. We can scan the code and push the results. I can also see all the applications. I know the portfolio of the applications that we have. I can see all the information about the organizations, the code, and the developers in one spot. It is good for the management and also for the development teams. If their supervisors want to know the security status of their applications, they can go there straight away and check that information. It is very good in this aspect.

Fortify SAST has helped in the remediation of potential vulnerabilities by using accurate and reliable results. I like that they use standards such as OWASP Top 10 or SANS Top 25. They are very good at this. When it finds any vulnerabilities, it shows you by the rank. You can filter by so many standards. It gives you a description of the vulnerability as well as recommendations on how to fix it. It also gives you some references if you want to read more. It is very good.

Fortify SAST has helped a lot to enable developers to build secure code from the start. We have many developers. They have the development skills, but they do not have security skills. Now, there is something that tells them how to write the code properly. For instance, they use a function, and then they get the recommendation to use another function. They do not know the other function. They go ahead and use it, and the code still runs as before, but it is safer. With time, people avoid these issues. It is like a spelling checker. You get recommendations while writing the code.

Fortify and Sonatype solutions help to maintain compliance with applicable regulations. Fortify SAST is built on top of very high standards such as OWASP Top 10, SANS Top 25, PCI DSS, etc. These are very repeatable security standards. It includes over a thousand vulnerability categories. It covers a lot of vulnerabilities.

Fortify SAST helps us reduce our risk exposure on applications through the discovery of vulnerabilities and weaknesses. They have something called rulepacks that basically are the guidelines. There are rulepacks for different languages. They are the security standards that the code will follow. These rulepacks are updated frequently by the Fortify team themselves, and we just have to feed them into Fortify Software Security Center so that it has updated information about vulnerabilities, and it can discover more. The more you discover and fix, the more secure and resilient code you will have.

Fortify SAST provides real-time feedback on security issues. When you scan, you get the results instantly. Sometimes, for certain code languages, it takes a little more time to scan, which can be frustrating, but it provides real-time feedback. You get a small description, and you also have the details. There is one tab for recommendations, and there is also a tab for references.

We recently had this activity where we wanted to integrate the tool with a pipeline. We are using Azure DevOps, and we managed to integrate that. It was straightforward. You get a plugin or an extension, and the code is pushed and scanned, and you get the results. It is straightforward. I can see it functional for such deployments. We are ready for the cloud and automation, but we are still in the testing phase.

Fortify SAST has helped free up our staff for other projects or tasks. Because it is very informative and clear, we have a lot fewer issues for which people come back to us. They come back to us if they think it is a false positive or if they need a waiver because they cannot fix it due to some limitations, but in the majority of cases, they can control and learn, and they can do it on their own. It helped us a lot in this aspect, but I do not have the metrics. We have been using it only for a few months, and we have a shortage of people. It has saved the communication time that we were spending on emails and reporting. We now have less of that. We all go to one place. Instead of sending me an email or having a phone call, developers now go to Fortify Software Security Center and put in what they think. For example, they will say that it is a false positive because of this and that. They will send it to me, and I will go to Fortify Software Security Center. I will read it and review it, and if I find it okay, I will give the go-ahead to get rid of it. Otherwise, we would need more discussion. It improves communication big time for me.

I like Fortify Software Security Center or Fortify SSC. Basically, this tool is installed on each developer's machine, but Fortify Software Security Center combines everything. We can meet there as security professionals and developers. The developers scan their code and publish the results there. We can then look at them from a security perspective and see whether they fixed the issues. We can agree on whether something is a false positive and make decisions. I like Fortify Software Security Center. It was not the way we had before. We used to have another tool, and it did not have this feature. I also like the fact that it supports many languages. It supports more than 30 languages. It covers a lot of what we do. Its configuration is a little bit tricky, but after you configure it, it is intuitive.

I also like the integration capability. It can integrate with many IDEs, such as IntelliJ, Eclipse, VS Code, etc. It integrates with all the main ones. It also can integrate with Nexus. It can integrate with Secure Code and Azure DevOps. This is really good to have something that can work with many vendors. It gives you versatility and flexibility.

We have integrated it with Azure DevOps for the pipeline, and we have integrated it with Secure Code. It is not a major integration. We have a plan to integrate it with Sonatype. I like to have everything in one place. All the integrations happen in the IDEs. We have people using Eclipse, IntelliJ, Visual Studio, VS Code, etc. We have integrated it with all the IDEs that we have here. The integration with IDEs was straightforward. You just install the plugin, add it to the IDE, and add your configuration. For Azure DevOps, we needed to add the binary, and it took a day or two because people were not familiar with it. For Secure Code, it was straightforward again. It is not hard to integrate. Its integration is easy.

One downside to it is that it is costly. I can see it only for enterprises. I cannot see it for small businesses or for individual use.

The configuration part is a little bit tricky. There is a learning curve there because it has multiple components. If someone has used another type of scanner, they would not think of the configuration intuitively. The configuration part can be better. Installation is straightforward, but the configuration can be better. It can be improved.

There is a learning curve. Before we started using this tool, I did a lot of sessions with the vendors themselves to give an overview to the people. I also did a small documentation on how to install it because there are many components here and there. You need to understand how everything is put together. They can integrate it or make it a simpler process.

During the short experience that we have had with it, we have noticed that some of the languages such as JavaScript and TypeScript consume high resources. They take a longer time to scan. Memory consumption is also very high for those languages. We are working with Fortify to find ways to optimize the scan. I noticed this with these types of languages. By nature, they take time.

It can be tricky if you want to exclude some files from scanning. For instance, if you do not want to scan and push testing files to Fortify Software Security Center, that is tricky with some IDEs, such as IntelliJ. We found that there is an Exclude feature that is not working. We reported that to them for future fixing. It needs some work on the plugins to make them consistent across IDEs and make them easier.

For integration with IDEs, they have so many plugins. For example, they have something called security analysis, and they have something called remediation. As a user, I would love to have them as one. Why should we have two plugins in the same IDE? Just give me one plugin that I can hook to the tool and use it. This is one thing. Some of the features in these plugins also need more testing. They are not consistent across all the IDEs. From what I saw, there are different options in these tools. For example, if you install it with IntelliJ, it will be different from VS Code. Some options are different, or one tool has more options than others. They can invest more in making them consistent.

We are a big company. We have different organizations. For our organization, we started using this solution this year, but other organizations have been using it for two years.

From what I have seen so far, it is very stable. It is a browser-based solution. You just log in to the website and see all your applications. From your machine, you can just push, and it will be published there. You click a scan, and your results will be in Fortify Software Security Center. It is straightforward and easy to use.

It is being used at multiple locations and in multiple buildings. The security requirements are very high in our environment, so not everything will work as you expect it because not everything is open. We struggle a bit, but it is required. We have around 60 people who use Fortify SAST.

We have not tested it yet, but they have something called ScanCentral. Currently, developers scan the code on their machines, and then they push it to Fortify Software Security Center. ScanCentral is a feature that we will start to experiment with soon where we offload the scan to a server. It will not utilize developers' resources. It will just initiate a scan, and it will use another system to scan. I have heard that you can have many of them implemented. I have not experienced it yet, but it seems like a cool feature to free the resources for developers because they need to deploy, compile, and fix. If it frees up their resources, it will be good.

I am very satisfied with their support. They are very nice people, and they are very helpful. I would rate their support a ten out of ten.

Positive

We were using IBM Appscan. We switched because of limitations and support. We found that developers were able to tweak it and play with it. They could play with the results. Its support had also ended, and it supported fewer languages. There were multiple reasons, and this is why we had to switch to something else.

I needed their help with the setup. It was mainly because our environment is a little bit strict. It is not the easiest environment to work in. It is not only applicable to Fortify; it is applicable to many other vendors, but with their help and support, it was doable. We have a very restricted environment. If you read a document and follow it, it should work, but because of our environment, we need to open this or that. We had access issues at the beginning, but once we resolved them, it was fine.

It took weeks because of the access issues that we had. We had to reach out to the vendor and ask them why it is behaving this way.

In terms of maintenance, we need to update rulepacks. We need to take care of the licenses. In the beginning, we used licenses from a neighbor until we got ours. We need to take care of the routine activities related to licensing and patching. If we find any vulnerability with the tool itself, we need to do patching. It is like any other tool.

We had people from the cloud team. We had people from the administration team. We had people from the database team. Overall, we had four or five people involved but not always together. When you configure the database, you will be with the database team. When you configure the cloud, you will be with the cloud team.

It is too early to say whether we have seen an ROI, but we have had a great communication and learning experience.

Identifying vulnerabilities using Fortify SAST early in the development lifecycle saves costs versus discovering vulnerabilities later in the software development lifecycle (SDLC). If you discover a vulnerability early, it is helpful. For instance, if you are writing Java code and you know that there is a limitation or vulnerability in that version of Java, it helps to plan your journey of development earlier. You get to know that your server does not support this version of Java. It helps you make decisions earlier in the process. Time is money. The earlier you handle things, the better it is.

There is a licensing fee, and if you bring them to the company and you want them to do the installation and the implementation in the beginning, there is a separate cost. Similarly, if you want consultation or training, there is a separate cost.

I see it as suitable only for enterprises. I do not see it suitable for a small business or individual use. In the future, if they have other versions for smaller organizations or individuals who want to install it on their machines and use it, it would be good.

To someone whose company is still using manual methods to find vulnerabilities, I would say that when you automate it, you control it. You give more power to people, especially from a security point of view.

I would recommend Fortify SAST if you have money and multiple teams. It is useful for multiple teams, but for a small company with one team of two to three people, I would not recommend it. If you have a big community with many organizations and many development teams, it is worth it.

Overall, I would rate Fortify SAST an eight out of ten.

The Lifecycle product is for protection, and licensing vulnerabilities issues, in our build lifecycle.

Without it we didn't have any way to detect vulnerabilities except through reactive measures. It's allowed us to be proactive in our approach to vulnerability detection.

Sonatype has also brought open-source intelligence and policy enforcement across our SDLC. It enforces the SDLC contributors to only use the proper and allowed libraries at the proper and allowed time in the lifecycle of development. The solution blocks undesirable open-source components from entering our development lifecycle. That's its whole point and it does it very well.

We use the solution to automate open-source governance and minimize risk. With our leaders across our different organizations, we set policies that govern what types of libraries can be used and what types of licenses can be used. We set those as settings in the tool and the tool manages that throughout the lifecycle, automatically.

It's making things more secure, and it's making them higher in quality, and it's helping us to find things earlier. In those situations where we do find an issue, or there is an industry issue later, we have the ability to know its impact rapidly and remediate more rapidly.

Its core features are the most valuable:

• protection
• scanning
• detection
• notification of vulnerabilities.

It's important for us as an enterprise to continually and dynamically protect our software development from threats and vulnerabilities, and to do that as early in the cycle as possible.

Also, the onboarding process is pretty smooth and easy. We didn't feel like it was a huge problem at all. We were able to get in there and have it start scanning pretty rapidly.

The data quality is really good. They've got some of the best in the industry as far as that is concerned. As a result, it helps us to resolve problems faster. The visibility of the data, as well as their features that allow us to query and search - and even use it in the development IDE - allow us to remediate and find things faster.

The solution also integrated well with our existing DevOps tool. That was of critical importance to us. We built it directly into our continuous integration cycles and that's allowed us to catch things at build time, as well as stop vulnerabilities from moving downstream.

Overall, it's pretty good. The drill-through and search capabilities are pretty good, they're not horrible. 

As far as the relationship of, and ease of finding the relationships between, libraries and applications across the whole enterprise goes, it still does that. They could make that a little smoother, although right now it's still pretty good. It's taking an eight out of ten and asking it to be a ten.

We've been using Nexus Lifecycle for over a year.
We use the Nexus repository for a long time.

It's very stable. We have not had any issues with it.

They're really good with scalability. We have an implementation that spans production use plus a disaster recovery area. The synchronization between those two and the high-availability are awesome.

We're at 100 or 150 licenses, maybe more. Developers are the main role as well as DevOps. The plan is to use it across every single application where we do development. We have a lot of applications, on the order of 500.

We have plans to expand usage, as far as the user base and the number of teams utilizing it go. 

Tech support is really available and very helpful.

We did not have a solution with this type of capabilities. We had some type of Nexus product but we layered this on top. We didn't have that capability.

The initial setup was straightforward. There weren't a lot of manual steps involved. There wasn't a ton of configuration. It has very smart defaults. There's not a high level of subject matter expertise required in the setup of the software. 

As for the decisions that you need to make about your policies, there are smart people out there to give you a lot of industry standards. But there is still a lot of work you need to do to make decisions for your enterprise. It can't do that no matter what it is. What you are going to do with those settings and the findings from those settings, that's the hard part. You have to make decisions about what to do with the data that it provides for you. That's not the setup, per se. That's just getting it to be very meaningful in your enterprise.

Our deployment was an interrupt-driven process because we had other work to do also. It took a few days.

The strategy for deployment was to involve legal, development, info security, and DevOps together - the leadership - to understand the tool's capabilities; to understand the defaults and also to come up with a strategy to manage the outcomes, the findings. That group of leadership had to set those settings and automatically be part of SDLC. Along with that, we had to implement a process that ensured that the findings - the breaks and the vulnerabilities that are found - would be visible. Notifications had to be made so that someone can triage and deal with them.

Deployment and maintenance require half a person. It's a side role because there's nothing to do most of the time. It's something you do occasionally, so we don't have a role dedicated to it.

We deployed it ourselves. We worked with Sonatype a little bit but we didn't need much from them. They were available when we needed them, but it was pretty straightforward.

The solution has improved the time it takes us to release secure apps to market. I can't approximate how much, there are too many factors there to consider.

If you find a problem reactively without the tool, there's the remediation cost, versus the savings of finding it in the first place. It would be really hard for me to go back right now and say how many things we found and how often because it's happening very dynamically. Those findings are not anything I can measure right now.

Then there are the things that we found that we might not have remediated. Maybe they were just okay, they weren't high-ranking and they weren't low-ranking errors. Now, we can decide that because we found them really early that we're not going to take that risk. Whereas before, we might've taken the risk - or not even have seen the risk. So it's hard to measure that. 

It's not literally speeding up our release to market. It's helping us avoid reactive costs and maintenance to the cycles after the fact. If an industry vulnerability is found, we get that notification really early.

We have seen a return on our investment. In some cases, where we've needed to find out the footprint of a certain library across our enterprise, we've been able to do that research in seconds or minutes, rather than long, drawn-out processes with people and teams involved to hunt it down through source code and the like.

As far as spinning up councils and people saying, "What's our vulnerability footprint look like?" we've been able to answer those questions much quicker and remediate quicker with other tools. Those things alone will probably pay for it. The safety stuff pays for it on its own too.

We've more recently also been able to leverage it as a solid containers repository solution.

Pricing is decent. It's not horrible. It's middle-of-the-road, as far as our ranking goes. They're a little bit more but that's also because they provide more. They put more manpower and time into their research - the details on their findings and the way they bring those to the surface. They offer some more features that others don't have, so I understand why it's a little bit more.

They were pretty good with us on pricing, working through it.

We looked at Artifactory as well. We went with Sonatype because it is more comprehensive, it's a market leader, has a great feature set, and support is really good. It's a good team and company. They provide much more granular details, as well as assistance in the remediation and understanding of vulnerabilities, than their competition.

In the early stages of planning and design for rolling this out, ensure that you get all of your stakeholders involved; those who will have an input on the policy settings. Also, ensure you have a process and people involved to deal with the findings. Have that baked into your standard enterprise processes. Don't just turn it on and not know what to do with it.

We use it to automate DevSecOps.

Previously, the developers would do their work and then it would be evaluated using something called penetration testing. With the results of the penetration testing they would go back and make changes, and then we would have to do the penetration testing again. That was a very long-winded process, whereas now, they can develop with confidence knowing that the libraries and binaries that they are using have already passed penetration testing. That saves a lot of time in the lifecycle. It's difficult to even quantify because it's so huge. But we're talking about reducing the development lifecycle by about 90 percent, minimum.

It has helped developer productivity. It's like working in the dark and all of a sudden you've got visibility. You can see exactly what you're using and you have suggestions so that, if you can't use something, you've got alternatives. That is huge.

When developers are consuming open-source libraries from the internet, it's able to automatically block the ones that are insecure. And it has the ability to make suggestions on the ones they should be using instead.

Also, you can get reports, either in PDF format or in JSON. If you get them in JSON you can have them ingested into something like Splunk, so you can mine those reports as well.

The application onboarding and Policy Grandfathering features are new and quite useful. They allow you to focus on what you're currently working on and the stuff that's grandfathered can go in your backlog. It's another feature that helps organize your workload.

The data is as good as can be. It's online, which means if a change is made to the Nexus database today, or within the hour, my developers will benefit instantly. The security features are discovered continuously. So if Nexus finds out that a library is no longer safe, they just have to flag it and, automatically, my developers will know. In addition to that, anything that I've used in the past will also flag up. Because it's proactive and it's live data, you know instantly if any part of your application is now vulnerable. Not only that but when you get the information about the vulnerability, part of the Lifecycle mechanism actually gives you alternatives that you can use.

It also integrates well with your existing DevOps tools. They've got very good plugins for most of the common DevOps tools, like Jenkins and GitHub. There are ways that you can work around things like TeamCity. The product is designed to help the DevOps process to be seamless in terms of security.

Regarding open-source intelligence and policy enforcement across the SDL, that's exactly what they're trying to do. They realized that there's so much ingestion of open-source software in most of the software development lifecycles, that there was a need to automate the detection of the ones that are not deemed to be safe. What Lifecycle does to its Firewall product is that, as the binaries are being ingested, it's able to fingerprint them. And because there's a fingerprint, it can check with the Sonatype website and tell you exactly what you're ingesting. If what you're ingesting is not secure, it can block it. Then, you can manually say, "Okay I understand, use this." Or you can go with the suggestion that Sonatype gives you, which is a more secure alternative. So we use it to automate open-source governance and to minimize risk.

There is also a feature called Continuous Monitoring. As time goes on we'll be able to know whether a platform is still secure or not because of this feature. It's integrated, it's proactive, it's exactly what you want for a security product.

They could do with making more plugins for the more common integration engines out there. Right now, it supports automation engine by Jenkins but it doesn't fully support something like TeamCity. That's where they could make the most improvements.

In terms of features, the reports natively come in as PDF or JSON. They should start thinking of another way to filter their reports. The reporting tool used by most enterprises, like Splunk and Elasticsearch, do not work as well with JSON. They should improve the reporting so that the format can be expanded.

The stability is very good. It probably needs to be improved a bit more. The cluster technology is first-generation and is still maturing. It needs to mature a bit more.

IQ is quite stable. It's a very simple engine, it takes something in, makes a decision, and then gives you the output.

The scalability is good but it can be improved. I think they're working on it, but it needs to be clusterable. The best case is to have a cluster, a native cluster, for IQ Server, to improve the availability.

Technical support is very good and the model that Sonatype has taken is that it is a product company, it is not a service company. You get this great support and it doesn't cost you anything. The support that they provide you is very good and it's free.

We weren't using a previous solution, we were using a different approach which was very old and which doesn't work. It was penetration testing which is very problematic. The way it worked was that an application was made and deployed. Then, you or a specialist firm tested the security of that application. You would get a report saying, "Okay, this is what we found." Then you would have to go back and change the application and, after that, get it tested again. You can see how much time it could take you - three, four, five, six months, a year, two years - to get your application tested. It was very inefficient.

The department that is concerned with best practices was obviously doing its homework and that's when they consulted Sonatype. They had some discussions and then the decision was made that this was the way forward. In fact, it is the only way.

The setup is straightforward. The product itself is counter-intuitive for most people, but the setup is very straightforward. It takes less than ten minutes to set up and deploy it. The policies can also be set up using normal human language. There is an interface to do that, so there's very little programming that's required to help the product become operational.

Our implementation strategy for a product like this is that you want it to be available all the time. Nexus, fortunately, has implemented a cluster for their repositories. You can set up a Nexus cluster for Nexus repositories. Lifecycle is not fully clusterable, so that's an improvement that is needed. They need to make it highly available as a cluster that is Active-Active. Right now, you need to have Active-Passive. 

But it's very easy to set up, it doesn't require super expertise. Any developer or any system admin can do it.

They've made Nexus Repository Manager clusterable. From what I've heard, they are trying to make Lifecycle, IQ Server, clusterable as well.

Since implementation, we have had four or five people involved in maintaining it and making improvements. 

It was done in-house by the people who were employed to work on this product. We did get support from Sonatype. They have what are called "success engineers." Sonatype, being a product type company, doesn't charge you for this service, but they will come and give you some tips if there's anything that you're not sure about, or they will show you what best practices are, which is very good. They are very knowledgeable.

From the word "go," with design and planning, any design that we did we passed on to them and discussed it with them. If there was anything that they didn't like or that diverted from best practices, they would advise about it.

For example, the cluster is supposed to be in the same data center. We did that and what would have suited us best is to have the cluster scattered among a couple of data centers. We did that and then we had to use a strategy were we replicated the data to another data center so that we had disaster recovery capabilities.

We see ROI in terms of better visibility into what we have in our developed software.

I think they looked at competitors but that wasn't my job. I'm familiar with the competitors. They are similar to Sonatype but, possibly, not as comprehensive. There are at least three or four other solutions using different but similar concepts. In my view, they're not as convenient or as good as Sonatype.

My advice is "do it yesterday." You save yourself a lot of money. Even during one, two, or three weeks, it's going to cost you a lot of money to fix the security vulnerabilities that you are ingesting in your development lifecycle. You could be avoiding that by using a product like Lifecycle.

With Lifecycle, the product itself, the intelligence is contained in the implementation called IQ Server. IQ Server has a component called Firewall. The Firewall, as the libraries are ingested into the organization, will scan each and every one of them. Depending on the policies, it's customizable as well. You can put policies there to say, if the library missed this criteria, block it. And you can say, if you block it, "But this library's okay, allow it in." You can waive policies. It's very highly customizable, such that you can block it at ingestion and you've got five other levels through which you could disallow a library. You could block a library from going into your staging or your development.

It will be used by over 2,000 developers in our organization, and that is just Phase One. Other phases will be rolled out, so it will be an enterprise deployment for the whole bank. It's a financial institution, an investment bank that is very big. We may have over 10,000 developers.

For all organizations - but most of all for financial institutions - security is very important. Somebody in the bank gave a mandate that we need to be more secure and this was implemented. The best way is to get the developers into the idea is that, by using the product, they'll be actually be saving themselves some time, because as far as security is concerned, they won't be required to change their programs as much.

I would give this product a nine out of ten, knowing that I'll have a full report of artifacts that would have been ingested into our organization - artifacts that are not secure - if I didn't have the product. That information is priceless.

We use the product as a SaaS analysis tool. We review static code. It allows you to find vulnerabilities.

The value that combining Fortify and Sonatype is that we use Fortify as a SaaS analysis tool. We review static code and Sonatype allows you to find vulnerabilities.

I use it as a security center. I review it for any kind of issues, whether for proof or to deny, the source code, the findings, and then the enterprise can go back and provide their recommendation for how to fix the issue. It is used to scan the code base.

As a security analyst, I like the management view. From there, you can review the code and review findings in order to approve, deny, or recommend. Their Software Security Center, which acts as a portal, is quite useful. It's a good overview. You can really see what's happening after you've developed something.

Fortify's AppSec testing is great for application portfolio inventory and project releases. It works both at a portfolio level and also at a project level.

They also give you the capability to click train of all your vulnerabilities that happened within Apache Crossroads support. You give them a history to keep track of them, how they've been developed, how they've been saved, to give you a way of tracking your issues and how they get resolved.

It's pretty easy to find vulnerabilities. Then, you go to the source. It is very good at tracking to see where the data or the issue enters into your source code so you can track it or go back to where it started.

Fortify helps remediate potential vulnerabilities by using more accurate, reliable results. They offer recommended remediation. I can go to the website tools to resolve issues and search for remediations. This helps our developers to build more secure code from the start.

It has reduced vulnerabilities. We've never had issues when we ran our scans. We're notified, and we're able to identify most of our vulnerabilities and fix them before anything goes to production. If you're running this on your CI/CD pipeline, notifications are in real-time.

The level of detail is very informative. It provides you with recommendations on how to fix items. And they provide you with other resources available for how to address the issues. You can also see the root cause.

It works well with cloud-native applications.

Fortify helped us to free up staff time since it helps us resolve issues faster.

It's helped us save costs as, if we catch a vulnerability faster, it's easier to fix than later.

Fortify and Sonatype help maintain compliance with the applicable regulations. We mostly use Sonatype for compliance and licenses. By combining both solutions together, it enables you to solve a lot of issues that may occur in the future.

It would be nice if they had a version suitable for single developers that could be more cost-effective and maybe faster to learn.

I've been Fortify for two or more years.

I've never had an issue with the solution crashing.

I've never had issues with scaling.

I've never had to contact technical support.

I was not involved with the initial deployment.

We only integrated the product with one other solution. It was easy to do so.

There is some general maintenance needed, such as adding or removing users and projects and things of that nature.

Their licensing is expensive.

I do not use the open-source components of Fortify. However, we use other tools for open-source stuff.

I'd advise people who are still using manual methods to find vulnerabilities to adopt some sort of scanner to cut the time spent by 100%.

I'd rate the solution ten out of ten.

I would advise other potential users that you need to make sure your source code can work with Fortify.

We have a few applications that we're developing that use several different languages. The first ones we did were Python and Yum Repository applications. Recently we've started scanning C and C++ applications that use Conan Package Manager. We will soon start doing node applications with NPM. Our use case is that we primarily rely on the IQ server to ensure we don't have open source dependencies in our applications that have security vulnerabilities, and to ensure that they're not using licenses our general counsel wants us to avoid using.

When I started to install the Nexus products and started to integrate them into our development cycle, it helped us construct or fill out our development process, in general. The build stages are a good template for us to help establish a structure that we could build our whole continuous integration and development process around. Now our git repos are tagged for different build stages that align with the Nexus Lifecycle build stages.

Going to the Nexus product encouraged me to look for a package manager solution for our C and C++ development. My customer success engineer, Derek, recommended that we go to one that Sonatype was considering integrating with the product, which was called Conan Package Manager. I started doing research with Conan and realized how beneficial it would be for our C and C++ development cycle. Transitioning to that has really changed our whole C and C++ development. It was because we needed to have Nexus scanning for our C applications and I needed Conan to do that.

It's because of Conan that we've reduced our build timelines from weeks because we have so many architectures that we build for. After we figured out how to use it, we can build everything with only a couple of commands. Now, it's a really integrated process for our C and C++ applications, from development to the build pipelines to the IQ scanning, and the Nexus Repository manager repositories that we're using for building and packaging. It's been a fun process.

In terms of the data quality, everything has been really good for our Python and our Yum repositories. I know that they are still building their capability for the Conan repositories, the C dependencies. Right now, what Derek has told me, is that Conan application are analyzed with what they call Low Quality Assessment, or LQA. Essentially, any package that has identified vulnerabilities will show up, otherwise, there's not much information on the package. So scanning for Conan is not as good as Python right now, but I know they're working on higher quality data for Conan packages.

Comparing LQA in Conan to something like the higher quality data available in Python repositories does show a difference. For example, Nexus IQ identified a vulnerability in a Python package that we don't use, but it's a transitive dependency in four packages that we do use. We discovered the root vulnerability causing the problem in our four packages with the higher quality data, but we may not have been to do that as easily with a vulnerability identified in multiple C packages without the higher quality data. I'm not sure.

Nexus will block undesirable open source components from entering our development life cycle. We've agreed on the governance of our policies for blocking builds automatically and we've set a date, for example, to start failing builds automatically on July 15.

It integrates very well with our existing DevOps tools. The Azure DevOps Nexus IQ plugin was really easy. All we did was go to our DevOps portal, go to the add-ins, and then search the list for Nexus. We just clicked on it and it installed in DevOps. There are a couple of help pages on Sonatype's webpage, and I send those to the developers, they add the IQ plugin to the build pipeline and it just works. It's really nice also because the IQ plugin for DevOps gets updated before I can even go check on it. They've released two updates since we installed it. Every time I hear from Derek that they've updated the IQ plugin, I go to the IQ plugin page on our DevOps server, and it's already been updated. It's totally seamless for us.

It has brought open-source intelligence and policy enforcement across our software development life cycle for almost all of our applications. We're still integrating it with all of our applications, but it definitely has brought the kind of intelligence that we needed.

Part of our use case is that we use Azure DevOps, so we have continuous integration, continuous deployment pipelines in Azure DevOps. The Nexus plugin for DevOps allows us to just include the IQ scan as part of the pipeline deployment. It's very seamless for our users. They don't even have to think about it until they have a violation. IQ informs them or stops the build, and the developers have to resolve it. 

The default policies were very good for us. We're using all of the default ones except for setting the warning and the stop features at different build stages. It definitely provides the flexibility we need.

We're not at the point in our deployment of the software to where we're doing automated git pulls and where it will automatically resolve vulnerabilities by downloading new packages. We haven't done that, but the integration with our Azure DevOps pipeline has been very seamless. I don't know of any developers that are using the integration with visual studio IDE.

The thing that they're already addressing is high-quality data for the Conan dependencies. They're very responsive to user needs. We're one of the first organizations to use Conan, so I identified a discrepancy in how they were scanning the dependencies, and they added the functionality within four weeks or so. The team is incredible. I can't think of any other ways that it could improve it.

When Conan support was first added to Nexus IQ, it would only scan one file type for dependencies. We don't use that specific method in Conan, but rather, another acceptable method for declaring dependencies that IQ wasn't scanning. I think the Sonatype developers  didn't even know about it because they learning Conan as much as we were. I informed them of the other file type for declaring dependencies and they quickly added the functionality.

I started installing it at the beginning of this year.

I've never had any problems with it, so it's been very stable.

I don't know about the scalability yet because we are small and we don't have that many applications or packages yet. I haven't had to scale it. I designed, from the beginning, the storage architecture of my Repository Manager to be scalable because I knew a lot of the large data will sit there. I designed that upfront to be scalable to other storage volumes or even other servers. I know there are features for having multiple IQ servers or Repository manager servers and load balancing or having automatic failover and things, but I haven't done those things yet.

Technical support has been great. I've never had any problems. When I do have an issue, sometimes I'll email Derek or I talk to him about it during our weekly meetings. He'll send off an email or a chat right away and get an answer back quickly about a resolution or resolution timeline.

We weren't doing automated vulnerability scans or license scanning. We were pulling straight from the public repositories so everybody had local caches of varying packages, which was different from the repositories of packages on our build servers. It was like the Wild West, but the Nexus products have helped us consolidate our repositories.

The primary reason why our senior director of product management decided he wanted to do this was that we develop sensitive software and need to ensure we don't have vulnerabilities from third party open source packages. We needed an automated way to do scanning instead of having the developers look at a list of their packages and compare them to a list of new vulnerabilities themselves. That would've been a nightmare. That central repository management was a secondary reason, but it was also important.

As important as vulnerability scanning, the licensing was essential to us too because around the time we were evaluating the Nexus product, there was a large company that was getting sued for violating open source GPL-2 license requirements. We wanted to avoid problems like that. Those are the two primary reasons.

The initial setup was easy. We're hosting on-prem and I put Nexus IQ on a VM I created according to Sonatype's recommended specs. It was really easy to install and it's really easy to update. The only thing that took a little longer to do was settings up HTTPS. It was my own fault because I had typos in configuration files that I'd overlooked. Following their instructions makes installation and upgrading really straightforward.

I did the IQ server and the repository manager server at the same time, and it took around less than a day for both of them.

When I first installed the two servers, I followed their recommended system requirements guidelines. In hindsight, because we are so small and we don't yet have that many applications, I probably could have started with IQ and Repository manager as containers. That would be okay for smaller companies that might be restricted on what resources they have available for hosting the servers. They could probably do containers in the beginning and then expand if they needed to later.

The deployment was given to me as a project. I didn't have an implementation strategy when I started building the servers, but Derek and I created implementation strategies as we went, after I installed the servers.

Initially after installing IQ and I putting some Python applications into, we had all of our policies set to warn and not fail builds automatically because we hadn't decided our governance process. That was part of the implementation strategy that we had to figure out. We had to decide a time to roll out our test applications and test groups. Derek was really instrumental in helping me see it in stages. We would test with the Python applications and then move on to other types of repositories and other types of applications for a broader adoption strategy.

Since the developers weren't doing really thorough vulnerability assessments in the past, I can only estimate how many hours it's saved and allowed them to continue developing the applications.

For example, if one of our pipeline applications has 15 dependencies and a developer had to look for vulnerabilities in that list of 15 dependencies, it could take a half-hour every day for one application. If they're developing six applications at once, then it could be a couple of hours a day per developer. It would quickly get out of hand.

I don't know anything about the pricing. I know that our license is the most encompassing one you can get. It includes the IQ server (Lifecyle, Firewall) and the Repository Manager Pro. Firewall is really useful for us to keep an eye on our proxy repositories for vulnerabilities. That's another layer of helping us make sure that we don't have vulnerable products. The expense is justifiable because of the potential to save a company a lot of money in lawsuits and risks from having vulnerable packages in their applications.

I don't have any reason to rate it less than 10 out of ten. It's been really solid, really helpful, and it will pay off hugely as we continue to expand.

We are in the education industry, but we are a developer-based company. We heavily use lots of public libraries. We use Sonatype Nexus Lifecycle mainly for protecting us from vulnerabilities and license copyright issues. We heavily depend on its database.

It's a hybrid. We have our on-premises instance for our internal security. With Sonatype itself, we use the cloud service, but we have a few modules on-premises, such as IQ Server and the report server. We have deployed those modules on AWS. As a company, we use cloud services 100 percent.

We have started rolling out to each of our feature teams and so far we have rolled it out to about 30 percent, but we can already see the benefit. It gives our teams easy visibility into the risk inside our code. "Risk" in this case can be copyright, more along the lines of compliance, and security itself, such as vulnerabilities.

From the legal and security perspectives, we have a huge concern about what we use in our product and our platform. Before using Sonatype we had a huge business risk. Since bringing in Sonatype, we have visibility for both the legal and security teams. It enables us to maintain the quality from the third-party libraries.

We follow the CI/CD methodology and Sonatype's impact is really huge because we are able to meet our continuous integration in the DevOps pipeline. The speed of that flow is noticeable. The impact is on both development and operations, together. The integration with the CI/CD pipeline is easy.

From the integration perspective, it is easy to use, out-of-the-box. The GUI is not complex.

I mainly use two modules, the report server and IQ Server. The value I get from IQ Server is that I get information on real business risks. Is something compliant, are we using the proper license?

With IQ Server we are currently running the default policy. We started deploying six months back and our main objectives were identifying any bad licenses in our library or product, and whether we are using any critically vulnerable assets. We have stuck with the default policies and they are giving us huge visibility and, as a result, we are putting a lot of effort into remediation.

In terms of the data quality and the database they have for open source, I'm impressed. For our requirements, the data we get seems to be updated well when it comes to license-type and vulnerabilities.

The solution also blocks undesirable open source components from entering our development lifecycle. We use it for controlling third-party libraries.

Nexus Lifecycle is multiple products. One drawback I've noticed is that there are some differences in the features between the products within Lifecycle. They need to maintain the same structure, but there are some slight differences.

Other than that, the tool is very user-friendly and gives the right reports to the right teams.

We have been using Sonatype Nexus Lifecycle for about the last six months.

Until now, we haven't faced any challenges on the stability front. If there's a challenge, if something is down, we definitely get a direct alert. We are happy with the stability part. Both the software and the infrastructure are good.

There are two aspects to the solution's scalability. The infrastructure scalability is the first part, and that is good. The second part is the developer and the licensing front. When we started the program, we had 60 developers but we now have double that number. There's flexibility on both the infra and the licensing. That is good, as of now.

When it comes to cultural adoption, when we put something new in the DevOps pipeline, the positive side is that we have a dedicated professional support team and there is a dedicated person. I'm on the security side, I'm not a developer. So the challenge for me is that when I go to the developers, they have a different language. That support person is always there to support me and I'm very happy with that support and the way they handle us as a customer. I can go to the development team or the department and say that, "If we need any support, let me know." I know that dedicated support person will be there for us. That's very much appreciated. That model is actually helping me to push our development teams to get into this new integration. The support model, with a dedicated person, is very useful.

We have frequent meetings with the person who manages the team, and our dedicated support person from Sonatype. If there's a new update it's like we have permanent support. They help us to update.

I would rate their support at nine out of 10.

We were using Sonatype open source, the repository server, for a long time, as a free edition and as a PoC. That's why we picked Sonatype Nexus Lifecycle. 

Before that, we were using a different solution for a period of time. We jumped to Sonatype from our previous solution because it had a limitation on the modules. If I go for a multiple module integration, there is additional cost, whereas with Sonatype, they bundle licenses. There's no limitation. I can go for any number of integrations. That's the reason we switched to Sonatype.

The initial setup was triggered from a template in the cloud, so it was easily set up.

With this implementation, the challenge is awareness. We have 14 development teams, but when we started the program there were 10. The number of development teams continues to increase and they use different tools and techniques in the CI/CD. From my side, in security, the idea is to make them aware. This would be the same whether the product was Sonatype or something else. Making them aware has been a very big challenge for me, to onboard them and make the product effective.

So the initial, technical deployment is easy, but to make it effective, we have had to bring that awareness into focus and do repeated training.

The initial deployment took one or two days, taking into account the infrastructure requirements in AWS. But that's not the issue. We deployed the server, but if nobody's using it there's no value from it. The value comes from being able to integrate all the developers. The dedicated support person was very useful in helping me create that awareness and value from it.

We use a lot of tools in our CI/CD, so the initial month was more of a feasibility test and proof of concept which was validated with multiple scenarios. Then we started onboarding teams, one per month. We work with the Agile methodology in two-week sprints. Each team picked the integration per its own Agile sprint timeline, based on the product owner's priorities. Within the two-week sprint for a given team, we are able to do a full integration for that team. But within those two weeks, if you look at the real effort, it would be a maximum of about two days, including troubleshooting. We have covered 30 to 40 percent of our teams so far. Within the next three to four months we may be able to complete the process and cover 100 percent.

When I started with Sonatype six months back, I knew that I wanted to do 10 integrations. When I started integrating with a development team, and getting them more usability, I understood the reality was not 10, it was actually 100. When I ran with another vendor, even though I started with a small price, when I looked at the total cost of ownership or the return on investment, it was totally different. With Sonatype there is definitely a return on investment in the number of integrations and the personal support. In that sense, there has been a lot of value. 

In addition, the bundled licensing is a huge difference and provides flexibility. We are not limited by the number of integrations, like in other products. We have flexibility and scalability. For us, the return of investment or value is huge, when it comes to the licensing model.

Cost is a drawback. It's somewhat costly.

As part of the procurement process in Alef, we have to do a minimum three-product evaluation. We evaluated Sonatype, a different solution, and there were two more in the pipeline. Based on that evaluation, technical and other, Sonatype came into the picture. 

The competing solution was actually cheaper, no doubt, but when we looked at the overall picture, the total cost of ownership after one year of integration, we understood it would be less with Sonatype, even though the initial price was less with the other products.

If you're going to be scaling and growing quickly, in a way you cannot predict, the Sonatype licensing model and feature set are definitely good.

Look at the scenario of the total cost after one year, not the initial stage. When we looked into the initial stage costs, there were vendors that cost less. But when you come to the integrations and real scenarios, that bill goes up. We had to clearly evaluate, not only the initial moment, but one year or two years down the line and consider the total cost of ownership.

Also, be sure to properly utilize the engineer allocated to your site to help support the developers.