Sonatype Lifecycle Reviews

We're consultants and it supports our primary banking group in Italy in terms of cybersecurity strategies.

Due to the mandatory use of Sonatype within the Italian banking industry, we rely on both Fortify and Sonatype to conduct a comprehensive analysis of the implemented code.

We use both SaaS and on-premise versions. The on-premises software helps the developer team continuously analyze tools. The SaaS version is used for centralized analysis in a testing environment for the IT security team.

Sonatype acts as a mandatory gatekeeper for accessing open-source libraries. Combining Sonatype and Fortify provides an invaluable holistic view of the application code developed by the factory. This includes both the library used by the factory to simplify development and the library itself, enabling comprehensive vulnerability detection. While Sonatype doesn't directly control the coding within the library, it effectively identifies vulnerabilities lurking within the open-source components. This offers significant value to developers who rely on these libraries, as it helps ensure their work is not compromised by unforeseen vulnerabilities. This information acts as a boost for developers, enabling them to leverage the library's functionality with greater confidence. The combination works like a black box for the developer. Sonatype and Fortify complete each other.

They are one of the market leaders, according to Gartner's Magic Quadrant.

We use Fortify to reduce application vulnerabilities significantly. In the test environment, we don't just use software code review. Before the use of Fortify, we would test the applications; however, using Fortify allows us to test internationally and to align with various compliance requirements, for example, European banking requirements.

It offers efficiency in the deployment of the application. It makes code review much easier pre-deployment. The Fortify FOD Portal is quite useful. It helps centrally manage everything and provides us with a 360-degree view of our AppSec team.

The solution truly supports the development team by giving a clear indication of vulnerabilities and providing suggestions on how to deal with vulnerabilities in a clear manner. There is a lot of useful analysis. It can help us map application libraries.

The software security center, in terms of managing and tracking risks, is good. It's very consistent. In Italy, the culture of risk analysis is very low. However, it provides very clear reporting. It offers great mapping. It maps both the tests and the severity of the vulnerability. It can help support the goals of risk analysis and help prioritize tasks to deal properly with risk. It can support risk analysis effectively.

The testing of the application portfolio is useful. It's also great for regulatory requests, including in the European community. The mapping of the application vulnerabilities provides us a way to respond according to risk.

It's very simple to use Fortify.

We can fully integrate with GitHub. However, we can also migrate in certain scenarios. We can prepare packages subject to analysis and send them to Fortify. It's not difficult. It's very simple.

When Fortify is on-premises with GitHub, remediation is easy. They can suggest and resolve issues directly. Fortify can offer guidance to the development team. So it's not only an identification tool, it's also a tool that can provide remediation for potential vulnerabilities.

Now, in the European Union, it's mandatory to analyze software. Fortify has become a necessary product. We might have started using it before there was a regulatory need. However, we now must have something like Fortify in place.

It helps us reduce risk exposure on applications through the discoverability of vulnerabilities and weaknesses. It's fully satisfactory. It ensures we are being fully compliant. We chose the solution as it is one of the market leaders, according to Gartner. We can only use the best in the market since it's so integral to our compliance requirements. It ensures we are always compliant with internal and external audits.

Fortify does provide real-time feedback on security problems. However, we don't use, at the moment, the functionality of real-time vulnerability analysis during the developer's typing of the code. We check the code afterward.

It's helped us free up staff time. We spend less time fixing software deployments. We've reduced the time to market of the implementation phase by 50%. We can test the applications faster, and we can support a number of projects with the same number of people.

Not all languages are supported in Fortify. They should expand their language offering.

We started to use Fortify in 2019.

We've contacted support in the past during the integration of Fortify. Support is quite proactive. We have periodical monthly calls with support.

Positive

We did not previously use a different solution.

I was not involved in the implementation. There was some integration involved in the setup. However, I can't speak to the level of difficulty involved.

We had the help of a systems integrator during the setup.

In terms of capabilities, the solution has all the capabilities necessary for the activity required. It's more economical than the other Big Three in the market as well. The price, overall, is quite good.

I'm a customer.

For those still using manual methods, I'd recommend something like Fortify that could accelerate the process of analysis. Manual methods require more effort for an organization, and those handling them must have high competence. I'm a modernist. I prefer to have continuous awareness in regard to vulnerabilities. Manual analysis, as well, can be very costly. It takes too much effort. Plus, if you have so many applications, it becomes impossible to manage manually. A business would not be able to support this.

We're fully satisfied with the solution. I'd rate the product ten out of ten. The results they provide are clear. There's continuous development of the product, and with new languages and functionality, it will continue to get better and better.

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 for checking our open source libraries for Java and .NET. I think they also have Python and R that some of my colleagues are using. And on the other side, of course, we also have the proxy to only download the open source libraries for our internet software development that are free of vulnerabilities and security issues.

It's deployed on-prem. We have internal servers.

Before we had Nexus Lifecycle, our software developers needed to clear each download from open source libraries. That meant they needed to scan the library on a separate PC, and then they would integrate it into their solutions, but it would be local and not available for the other developers. Now, we have an automatic process for downloading open source libraries, and this has removed a huge effort for all of our software developers. That is the big advantage, that we have an automated software development pipeline, which is something we did not have before. All of our developers are happy to have the solution.

Another benefit is connected to the fact that we also have applications we host for external users and those users can obtain a very good report about which external, open source libraries we are using, and their security status. 

We get email notifications if a certain library has a security issue, like Log4j. We are informed very early and we can check into it and act on it. This is the most valuable feature.

Also, the integrations into developer tooling are quite nice. I have the integration for Eclipse and for Visual Studio. Colleagues are using the Javascript IDE from JetBrains called WebStorm and there is an integration for that from Nexus Lifecycle as well. I have not heard about anything that is not working. It's also quite easy to integrate it. You just need to set up a project or an app and then you just make the connection in all the tools you're using.

We have also set up certain organizations for our company, within the Nexus tool, such as groups or departments. Within these groups, we have the different applications they're working with. This is a structure that Sonatype recommended we implement.

We got a lot of annotations for certain libraries when it comes to Java, but my feeling, and the feeling of a colleague as well, is that we don't get as many for critical libraries when it comes to .NET, as if most of them are really fine. It's true that we have more Java applications than .NET, but the number of our applications in the .NET area will increase. Again, it's just an impression, but it seems that the annotations for .NET are not the same as for Java. It would be good if Sonatype would check the status of annotations for .NET packages.

Again, I note that we are just starting to use an open source library from NuGet for the .NET area, while we have been using it for Java for several years and we are using more packages. For .NET, it's evolving. But my impression is that annotations are more focused on Java, and that in .NET we just do not see as many security issues as in Java. It could be fine, but maybe Sopatype started with Java and then expanded the portfolio to .NET and to other languages. This is something which could be further checked.

It could also be the fact that we have had Java applications for around 20 years, using open source libraries. When you go to the newer versions, you need to check and test. Whereas the .NET applications are evolving and are using open source libraries, and the .NET side is really new for our organization.

I have been using Sonatype Nexus Lifecycle for around one year.

The stability is fine. I have not struggled with it. The solution is working, it's available. But this is something I can't tell you much about it because the server infrastructure and installation are done by our infrastructure team. I'm not sure if they are struggling with availability of the services.

The scalability, currently, is fine, because the performance is fine. It was important to have a structure at the beginning, a way to set up different departments and groups. Now, if we have a new group that will use IQ Server or Nexus Lifecycle, we can just add it and it will be managed by the department. That makes it really good and scalable.

Nexus was a pilot, where some of my colleagues were using it but now it has spread to our whole organization and more colleagues are using it.

An evaluation of Sonatype's technical support is more a question for our infrastructure team.

We did have some workshops with Sonatype about using Nexus Lifecycle and IQ Server, and they were quite nice. They made presentations and we could ask our questions. There is also the offer to have workshops about new topics, but I can't say much about the really technical questions.

However, from my point of view, the communication with Sonatype is really good. They take care of our requests and issues and answer them.

This is the first solution we're using. We had a Nexus repository for several years, and we added Nexus Lifecycle on top in the last one to two years. Before, we would just manually download libraries and clear them by checking the download status. It was a manual task and now it's automated.

I wasn't involved in the server installation. From my point of view, the deployment was quite easy. The servers were set up—a test instance and a production instance. In the test instance, we can play around and see if everything is working.

The IDE integration was quite easy because you just have to download the plugins and then set up the URL and the user and password. With Jenkins, we had to play around a little bit, but it was not that tricky. The integration is really nice because the plugins work quite well.

Because we have only had Lifecycle in production for around one year, it's too early to know if it has improved the time it takes us to release secure apps to market.

But it has definitely increased developer productivity. If you manually download a package, you're not sure if it is the right package because you cannot test it. But now, we can automatically download packages. It's much more effective and more productive for each software developer using it. I would estimate we have seen a 20 percent increase in productivity.

It's also helping our security because that is an aspect we did not check before. That is new for us and very valuable.

We have internal help pages for new software developers with explanations about how they can get access to Nexus Lifecycle and how they can set up new organizations, new applications, and how the IDE integration is done.

We're using it to change the way we do our open-source. We used to actually save our open-source and now we're moving towards a firewall approach where we are proxy to Maven repos or NPM repos, and we are using those proxies so that we can keep ourselves from pulling in known bad components at build time. We're able to be more proactive on our builds.

It's allowed our developers, instead of waiting till the last minute before a release, to know well ahead of time that the components are bad and they are able to proactively select different components that don't have a vulnerability or a licensing issue.

Also, the solution's data quality seems to be good. We haven't had any issues. We're definitely able to solve problems a lot faster and get answers to the developers a lot faster.

And Nexus Lifecycle integrates well with your existing DevOps tools. We were able to put it right into our build pipelines. We use Jenkins and we're able to stop the builds right in the actual build process whenever there's a quarantined item.

In addition, it has brought open-source intelligence and policy enforcement across our SDLC. It has totally changed the way we do our process. We have been able to speed up the approval process of OSS. Given the policies, we're able to say, "These are okay to use." We've been able to put in guardrails to allow development to move faster using the product. Our pipelines are automated and it is definitely a key component of our automation.

Finally, the developers like it because they're able to see and fix their issues right away. That has improved. For example, let's say a developer had to come to us and said, "Hey, scan this. I want to use it," and we scan it and it has a vulnerability. They've already asked us to do something that they could have done through the firewall product or Lifecycle. Suppose it takes us a day and then we turn around and say, "Okay, here are the results," and we say they can use this version of that product. They've got to download it and see if it works. So we're already saving a day there. But then let's say they have to send it off to security to get approval on something that security would probably approve anyways. It's just they didn't know security would approve it. They would have to wait two or three days for security to come back and give them an answer. So we're looking at possibly saving four days on a piece of code.

The proxy repository is probably the most valuable feature to us because it allows us to be more proactive in our builds. We're no longer tied to saving components to our repository.

The default policies are good, they're a good start. They're a great place to start when you are looking to build your own policies. We mostly use the default policies, perhaps with changes here and there. It's deceptively easy to understand. It definitely provides the flexibility we need. There's a lot more stuff that you can get into. It definitely requires training to properly use the policies.

We like the integrations into developer tooling. We use the Lifecycle piece for some of our developers and it integrates easily into Eclipse and into Visual Studio code. It's a good product for that.

It would be helpful if it had a more detailed view of what has been quarantined, for people who don't have Lifecycle licenses. Other than that, it's pretty good.

We've been using it for about a year now.

The stability has been great. We haven't had any issues in the year that we've had it running. So far, so good.

It's probably not that scalable in its current state. That has to do with the way that the applications are designed. I think they're working on that when they start working on the HA solutions. For Nexus and Nexus IQ I think that will change. But right now, it's not very scalable.

Sonatype's technical support for this solution has been great. They answer my questions, even my stupid questions. I might be asking them, "Hey, how do I do this? I can't find it." and they'll say "Oh, it's just this button right here." They never make me feel too bad about it.

We didn't have something that does what a firewall does. We used a different repository and used Nexus IQ to do the enforcement of policies by scanning OSS's individually. It's nice having it happen automatically on the repositories now.

The directions on the site are good. Once you follow those, you're good. But if you're looking to set it up by just clicking around, you will probably have a hard time figuring it out. But it's easy once you know what you're doing.

From inserting the license file to proxying my first repos, it took about an hour, at the most.

We were doing a conversion. So the implementation strategy, if we're just talking about firewall, was that we already had Nexus. We bought Nexus and the firewall at the same time. Once Nexus was installed and set up, it was a matter of importing our repositories from Artifactory Pro and then connecting the proxy repositories. I can't say there was any "super-strategy." It was just turning it on, getting it going, and then moving the developers over to it using their settings, XML, etc. And we had to set our NPM RC files to point to our new repository using the firewall and, for those repositories that have a firewall, they had to be turned on with them.

We did it ourselves.

We don't have any evidence that the solution improves the time it takes us to release secure apps to market because we haven't released an app yet, but I'm sure it will.

Just the dev happiness is already a type of ROI, in addition to how fast they're able to go using it.

We pay yearly.

I looked at a few others, like Black Duck, and I was not impressed by them. I didn't get a chance to actually use Black Duck but everything I read said that Black Duck came up with more false positives than Sonatype.

My advice would be to use it as soon as you can. Get it implemented into your environment as quickly as you can because it's going to help. Once you get it, get your devs on it because they're going to thank you for it.

All of our development is happening using the firewall. All our build pipelines are going through there. As far as licensed users go who can look at Nexus, we've got about 35. They range from devs to security personnel to DevOps people.

All our applications are moving over to it, so that's definitely going to increase the usage. We've got about another 200 applications on the board that will come into our greenfield process so they will be pulled straight into that repository using the firewall. It's definitely going to keep growing.

For deployment and maintenance of this solution there is really just our DevOps team of about four people, but I'm primarily responsible.

I would rate it a 10 out of 10. It does everything I need it to do.

We use it in the pipeline. So, software development is done in a pipeline in automated steps. One of those steps is Quality Assurance for which we use, amongst others, Sonatype, and this is done automatically. Based upon the outcome of this scan, the software product can proceed to the next step, or its blocks need to be rebuilt with updates.

We are using Nexus IQ Server 114, and we're about to upgrade to 122.

It improves the overall hygiene of the source code. We have a lot of scans going on every day. They are in the thousands. If high critical vulnerabilities are detected, of course, that is good. It is already proving its value to us down the line because these vulnerabilities do not reach production.

Data quality helps us solve problems faster. We get the info on what's vulnerable, and most of the time, we get advice for an upgraded version that can be implemented right away. That's very valuable.

It brought open-source intelligence and policy enforcement across our SDLC. It is the tool that we use for open-source scanning and third-party dependency scanning. So, it brings a lot of value to us from that perspective. 50% of the code that we use is open-source. So, it is important to scan it for all kinds of vulnerabilities. It is very powerful, and it brings a lot of security to us. It can block undesirable open-source components from entering our development life-cycle.

It secures the software supply chain because it scans the packages that we get from our vendors, but we don't use it to secure our pipelines or steps in the build process. The build process itself is not secured by Nexus IQ.

It improves the overall health and security of the software supply chain. Anything that is detected can be blocked.

The quality or the profiles that you can set are most valuable. The remediation of issues that you can do and how the information is offered is also valuable.

Its integration with our tool landscape is very valuable. It is the interaction with account management and technical consultants.

The default policies and the policy engine are very good. Most of what we have is the default. It is also possible to create your own policies and custom rules, but we only do that for a handful of exceptions. We are very pleased with the default policies and settings. It provides us the flexibility we need because we can use it in our own customized settings. It is flexible enough for us to work with.

The user interface needs to be improved. It is slow for us. We use Nexus IQ mostly via APIs. We don't use the interface that much, but when we use it, certain areas are just unresponsive or very slow to load. So, performance-wise, the UI is not fast enough for us, but we don't use it that much anyway.

I have been using this solution for about five years. It was being used prior to me engaging with it. So, it was already there.

It is very stable. There are no complaints. It is good in terms of availability.

We don't need to scale it. At this moment, it is right-sized for us. So, I don't see any scalability going on right now. We do self-hosting on our own internal platform. The resources that are available are not scalable, so to say. They are right-sized.

We have between 750 and 1,250 users. The developers are the biggest part. We also have our operations support team that deals with upgrades, patch management, installation, and the Infra stuff. There are about 10 people. They don't only work on Nexus IQ, of course, but that's part of their job. There is also the security team, which is my team. It has about 10 people. We use Nexus IQ for all kinds of security review activities. We also have five metrics people who use these tools to gather metrics. They also use Nexus IQ.

I have contacted them, and I would rate them a seven out of 10. Like every big company that you contact for support, you can get people who are well aware of your situation or less aware. Depending on who you get at the support desk, you might get immediate feedback or the right answer, or you might be going back and forth to get the right information. You don't have a single contact person for all your support, so the quality can change based on who you talk to.

Our company didn't use any other solution.

We have a team of about 10 people for upgrading the tool, patching the tool, migrating XIQ from our own platform to a public cloud platform, and creating system rules and policies.

For Nexus IQ, I have not seen any research that has been done for ROI. I am aware of other tools but not Nexus IQ.

There are additional costs in commercial offerings for add-ons such as Nexus Container or IDE Advanced Toolkit. They come with additional fees or licenses. 

We always explore other tools. For every tool that we have, we constantly look at what's available. Every couple of years, we do an evaluation to see if there are replacements that are better suited to our needs. Our requirements might change over time. Our entire circumstance might also change from being on-premise to a fully-cloud company, where we might need to fulfill different types of needs. So, of course, we explore what are the best options for us. We stayed with Nexus IQ because they're a pleasant company to work with, and they offer a good product. 

I would advise making sure that your developers are aware of why you are going to scan the source codes for vulnerabilities. An awareness training or awareness program on open-source vulnerabilities goes hand in hand with implementing such a tool because the tool is there to enforce policies, etc. If your community developer knows how to build secure software and how to look at open-source, it will drastically reduce the findings in the tool and create a healthy software landscape. So, awareness of secure coding principles should accompany the installation of such a tool.

Although we are very familiar with the concepts and the topics, we don't make use of integration with IDEs. We do not support automated pull requests yet. It would take time for us to implement, and there are other things that we are busy with. It would depend on how things proceed. We also don't use Nexus Container. 

It has not improved the time to release secure apps to market. It has also not increased developer productivity. In the short term, it decreases developer productivity because they have to fix stuff that otherwise would go undetected. So, productivity is hampered if you are confronted with vulnerabilities that you need to fix. Therefore, being more secure in the short term doesn't make you more productive. If you are aware of why you need to look at certain things, it can bring productivity in the long term.

The biggest lesson that we have learned from using Nexus IQ is that with open-source, so many things can go wrong. Most of the vulnerabilities that you have in your software are due to the bad usage of open-source components.

I would rate this solution an eight out of 10.

We are a development company and a staff provider, so we have 100 plus developers and use the open-source library.

The IQ server and repo are the most valuable.

The reporting could be better.

We have been using this solution for about a year and a half, and the IQ server is 148.

We've been running for almost a year and a half and have not faced any service degradation or outage. There have been times when we need to upgrade and plan, so I rate the stability a nine out of ten.

I rate the scalability an eight out of ten.

The technical support is good because we have a success manager allocated to us. So we usually go to the success manager for support, and it's really good. Otherwise, we never go to the support portal. The success manager can help us immediately through email.

The initial setup was straightforward, and it is cloud-based. It's hybrid, so the main items are in cloud, but we use on-premises to support our design. We have almost 14 development teams working with different languages. It took two weeks for complete coverage and deployment readiness, but everything took about four to six months.

We completed the deployment in-house, so we had a success manager from Sonatype. Sonatype also provides some guidelines. I completed the deployment, and I am not a technical person. There's a shortage of resources, and I was able to do it, so it is a one-person job. A medium-skilled person can complete it with an average skill set. However, you may need a dedicated resource if you want to move to a maturity level.

We have about 100 developers using this solution. Sometimes we have an extra workload, but we maintain those 100 developers at the core on average. That is an organizational policy so that the workload will be balanced accordingly.

We are a development company, and we use open-source heavily, like 95% source code. So the return on investment on the main security check is very high.

Their pricing is within the same range as the enterprise bundle, around $50,000 US dollars.

I rate the solution an eight out of ten because of the compatibility and the cost. In the market, some products cost less. Regarding advice, Sonatype Nexus Lifecycle provides many capabilities. If you want to use it, you should be able to prioritize your need for it. In addition, you should be ready to clear through the pipeline, which will make the program successful. If they are a traditional company and opting for IQ, there may be challenges, and there will be better results if it is already adopted.

We maintain several applications that utilize a mix of custom PHP packages and native functionality. When a package becomes outdated or a security vulnerability emerges within one, our lifecycle management system flags the issue and assigns a threat level of critical, high, or moderate. We prioritize mitigation based on severity, addressing critical issues first. Additionally, we've integrated Fortify on Demand into our build pipeline. This tool scans our codebase for static vulnerabilities as new code is built and performs dynamic scans for potential runtime issues once builds are deployed.

We implemented Fortify Static Code Analyzer to ensure our platform meets security standards, stays up-to-date with threats, and streamlines security remediation.

We use the Fortify Software Security Center to provide a wide view for our AppSec team.

The Fortify Static Code Analyzer aids in remediating potential vulnerabilities through its accurate and reliable results. It serves as a critical gatekeeper for production applications. If an application fails the Fortify on Demand scan, it does not enter the deployment phase and is effectively halted from release.

Fortify Static Code Analyzer helps our developers build secure code.

While we were able to manage our security issues before tools like Fortify Static Code Analyzer, we relied on manual identification and documentation of vulnerabilities. However, this lacked the efficiency and scalability of an automated solution.

Fortify and Sonatype solutions help us ensure compliance with applicable regulations. We gain valuable insights into relevant regulations directly from vulnerability assessments, which helps maintain compliance with specific regulations.

Fortify Static Code Analyzer offers feedback on security vulnerabilities. Its static and dynamic scan, particularly for Fortify on Demand, provides automated feedback. For example, the dynamic scan might take around 20 minutes to settle, depending on the specifics. However, this turnaround time is significantly faster than relying on the entire security team to conduct manual testing. It can sometimes provide excessive detail that is not directly pertinent, leading to inefficiencies in extracting the relevant information.

I believe Fortify Static Code Analyzer is a valuable tool for implementing shift-left security in cloud-native applications. I intend to leverage it for personal projects, starting with my current app development. I plan to make it my go-to standard for application security.

The ability to identify vulnerabilities using Fortify Static Code Analyzer early in the development life cycle has saved us costs.

Integrating Fortify Static Code Analyzer is not complicated after the first integration.

Automating the Jenkins plugins and the build title is a big plus.

Fortify Static Code Analyzer has a bit of a learning curve, and I don't find it particularly helpful in narrowing down the vulnerabilities we should prioritize. It throws everything at us at once, which can be overwhelming. While it's not a major issue, I'd like to see it focus on critical vulnerabilities and highlight them upfront. Furthermore, categorizing critical vulnerabilities by platform-specific vulnerabilities and relevance to supported features would be incredibly beneficial.

While Fortify Static Code Analyzer has some merit, I believe it still has significant room for improvement. We have encountered a high number of false positives, which has been a major obstacle and resource drain.

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

We use it in combination with Sonatype Lifecycle. We use Sonatype for all of our packages. It's for any outdated packages that we have. Before we build a package out to production, we can see if we need to update it. Having that alongside Fortify makes it our own one-stop shop for security. It makes our builds a lot smoother.

I would rate the stability a seven out of ten. Fortify Static Code Analyzer suffers from limitations in handling versioning issues. It necessitates specific guidelines or calls to operate efficiently otherwise it doesn't provide feedback.

We are still trying to get an impression of the scalability. We have scaled it on all of our products and it seems to be good. I would rate the scalability an eight out of ten.

The technical support is adequate, but I did experience a frustrating issue once. They could benefit from a dedicated team to handle support requests more efficiently. Messaging them and relying solely on the support ticket system feels outdated, especially considering the premium price we pay. At least a live chat option would be a significant improvement, as the current system was quite cumbersome and unresponsive.

Neutral

The initial deployment was a bit more challenging than anticipated. There was a learning curve involved, and supporting the plugin for our Jenkins environment presented a significant obstacle.

To overcome these hurdles, we decided to evaluate the Fortify Static Code Analyzer. We began by integrating it into smaller projects first, which allowed us to gain familiarity with its capabilities. We then gradually branched out to our larger projects, building upon our understanding. This involved uploading code bases, analyzing the scans, and interpreting the results. By taking this incremental approach, we were able to effectively expand.

Four people were involved in the deployment.

We have seen a return on investment using Fortify Static Code Analyzer.

We evaluated other solutions but ultimately selected Fortify Static Code Analyzer for its simplicity and its ability to tailor to our build cycle.

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

Since we started the integration of Fortify Static Code Analyzer from the beginning, it has not yet significantly freed up the time of our security team. However, it has helped make the process more efficient, and the integration is still in progress.

Organizations that are still using manual methods to find vulnerabilities should try Fortify Static Code Analyzer. If it is within their budget, Fortify Static Code Analyzer will work well for them.

We utilize the Fortify Static Code Analyzer across various locations and projects, making it the go-to tool for security analysis in most of our development initiatives. We are a large corporation with high traffic.

For larger platforms with strong automation needs, I recommend Fortify Static Code Analyzer.

We use the Nexus IQ Server. That is the only product that we use, though there are other affiliated products Sonatype offers which integrates with it. We use it to categorize and index all libraries used in our software. Every time that a new build is created in our CI server, Nexus IQ server will check exactly what libraries that we're using. It does this for our Java libraries, JavaScript, and other things that it finds. Then, it checks a number of things for each of those libraries. E.g., it checks the license that is being used in it. Sometimes with open source software, the license is a bit more restrictive than might be convenient for what you are doing. Maybe it doesn't allow you to make changes to the library. Or, it's free to use for nonprofits, but if you're using a product which does make a profit, then you might have to purchase a license. Therefore, it protects us from accidentally misusing open source software and is protection against legal issues.

A bigger, ongoing use case is security. Sonatype checks security vulnerabilities that come up for all these libraries. Oftentimes, as a developer, you add a library that you want to use, and then you might check for security issues. Sometimes a problem comes up after your product is already live. IQ Server checks all libraries that we're using for security issues, reporting these, and allowing us to go through and see them to determine, "Is this something that we can waive?" It might be a very specific use case which doesn't actually affect us or we might have to mitigate it. Also, if a vulnerability or security issue is found in libraries later, it will send out alerts and notifications if a library is being used in our production environment, letting us know there is an issue. This allows us to address it right away, then we can make the decision, "Do we want to do a hotfix to mitigate this? Or is it something that isn't an issue in our case because we're not using it in a way that exposes the vulnerability?" This gives us peace of mind that we will be notified when these types of things occur, so we can then respond to them. 

One of the things that it detected was a small library that we use to generate PDFs. It pointed out this needed a purchased license. We had already bought the license because we did have some people in-house who were aware of that. However, it's still one of those things where I can see this easily going wrong for companies who are younger and don't pay as much attention to this type of stuff.

When IQ Server finds a problem a Jira ticket is created and an email is sent out. Usually, one of our technical people will check it out right away to see if this is something that can be simply scheduled in the next sprint or if it's something big. If it is something big that affects us and needs to be addressed right away, I know that we would likely be able to address it almost immediately, either by doing an update of the library or mitigation. We should be able to start work on it almost immediately. In very severe cases, we should be able to do this in just a matter of hours. We should be able to update our environments after we get a notification that the problem exists.

We have had cases where we wanted to add certain libraries, but the Nexus IQ IDE plugin showed there were some security issues with this library. Instead of using it, we found an alternative right away. Because it is easy to have this information available, it saves us the hassle of having to refactor later.

Nexus IQ Server has made it easier to address company or legal policies when it comes to the libraries we use. Sometimes, as a developer, you don't think about the legal aspects of a free and open source software. While we were aware that you occasionally need to buy a license for something, we're also paranoid of falling victim to giant lawsuits because we overlooked something in the license. We did have some enforcement of this before using Nexus IQ Server, but it would be done periodically and sometimes long after implementation of a problematic library was already done. Now it's all categorized in one place and we can very easily check license issues ahead of time. The awareness was there before, but now we have a definite way that it's all completely indexed. Enforcement is now easier and nothing can slip through the cracks. Everything is checked and will be reviewed unless someone specifically says, "This license is okay and you can use it."

It triggered a review of everything that's used and their licenses, since there are so many different open source licenses. Someone does have to go through each license and actually check off on it, with IQ Server we were able to do that more easily. It provides an ease of mind that if anything really bad would pop up, then it would easily show us in the report that it's there.

Since we started using IQ Server we have received a number of alerts regarding newly discovered security vulnerabilities in libraries we use in production. When that happens we delve in to it almost immediately. Up until now all of them have turned out to be for specific use cases that didn't actually occur in production. Just as a precaution though, we still schedule tickets to have such libraries updated anyway, in case it's later discovered that there are additional use cases that would allow exploitation of the vulnerability in production.

IQ Server also checks the overall quality of library. Often as a developer, to solve a certain programming problem we do some research online and may find suggested open source libraries that would address what we need. However, we don't always check how old it is or how maintained it is, but that is another thing that IQ Server will point out. "This version (or the whole library) you are using is like five to six years old. Maybe it's time to check if there are alternatives which are better kept up." That's another useful thing for us.

We enjoy how it works together with other stuff that we have. We integrated it with Jira to keep track of things. We have it set up so it will generate tickets in Jira automatically when it finds something, then those can be added to our sprints.

The quality of data seems very thorough. It compiles data from a couple of different sources. Sonatype double checks the vulnerability itself. I've seen instances where there will be a message saying something like, "According to official sources, this only occurs in version 4.2 or later, but our research team indicates that the vulnerability also exists in versions 3.x." This shows IQ Server gives you more information than what we previously would find, unless we did a lot of research and happened to stumble on that piece of information. Busy developers will usually prefer to spend the majority of their time implementing features and fixing bugs to meet customer time lines rather than indefinitely research possible vulnerabilities in a library they want to use. The information that we're getting through IQ Server makes it all easily accessible, and it's also thorough and comes with steps and descriptions of when this issue occurs for specific use cases, so it allows our developers to not lose a lot of time on research.

One of the things that we specifically did ask for is support for transitive dependencies. Sometimes a dependency that we define in our POM file for a certain library will be dependent on other stuff and we will pull that stuff in, then you get a cascade of libraries that are pulled in. This caused confusing to us at first, because we would see a component that would have security ticket or security notification on it and wonder "Where is this coming in from?" Because when we checked what we defined as our dependencies it's not there. It didn't take us too long effort to realize that it was a transitive dependency pulled in by something else, but the question then remains "Which dependency is doing that?" This is the biggest thing that we have talked to Sonatype about. Even though we have found an way to see where transitive dependencies are coming from, it would be nice if this was visible through IQ Server as well.

Another issue is that, although Sonatype categorizes and indexes a lot of different repositories, it doesn't index every single repo in existence. One of the components we used switched where it came from, so a later version was actually coming from a different repository that Sonatype didn't index, as it was relatively smaller. They cover a large amount of available libraries, but they don't cover 100 percent of them. In this case, that component that was marked as an unknown component. When we get this kind of notification, we have to double check it. That is how we found out that these are components aren't covered by Sonatype yet. We have put in requests to have this particular repository added to the sources Sonatype indexes. It's something to be aware of if you use obscure repositories.

We set it up in July 2019. Therefore, we have been using it about seven or eight months.

The stability is good. We have never had an issue with it being unreachable. I've not noticed any downtime with it. 

The single issue and change that our administrator ran into was that after he setup the solution, it used a file database locally. After he switched it from running in the foreground to running as a service on a VM, we realized that the database was gone, it had somehow reset. He was able to find the previous file used as the database though and successfully migrated the data to Postgres. That was all the way in the start and we noticed the issue right away. After that, we've had no issues with it.

Our system administrator has not had any issues installing updates to IQ Server.

We haven't had any major security things that we had to fix last minute or on production, which is a good thing. However, we have had vulnerability issues come up. We were able to check them out and notice that they wouldn't affect us immediately because they applied to a specific use case which doesn't occur in our application. However, it does show that things come up. Security issues are found, and if we would've done a manual scan with our previous product/project, we may not have known that something happening on production or we would have found it a lot later. Whereas now, these things pop up right away. It has seemingly increased the overall stability and how fast we can respond to things.

We think about software issues in healthcare. We always want to be very careful of security things in this application because of HIPAA and patient privacy and vulnerabilities to applications from things like ransomware. We get questions about this stuff from potential clients about how we can protect ourselves. We have continuous monitoring of security vulnerabilities, which is very good advertisement for our company. This was not something we could say before because we'd have to do it manually. Sometimes, a few months would go by before we could run another scan.

We have a relatively small number of people using IQ Server, consisting mostly of a few developers and project managers. Under those conditions it is performing very well. We have plenty of room to grow with it. We don't have any huge plans to expand use of the solution because it's fulfilling our current needs.

We filed a ticket for some unknown components and got quick feedback. They gave us pointers on how to figure out what it is. One of the things that we were impressed with was that they wanted to do a review of how we were using it after a few months. I guess this is a problem with us technical people. We often don't like reading manuals and like to figure out how stuff works. I initially was skeptical, but I figured that if they were offering it we should do it.

They had us show them how we had set it up, then they had a number of pointers for how we could improve it. E.g., we weren't fully using the JIRA integration and notifications and they pointed that out. There were a few other things they pointed out as well, such as a list of things for us to double check, like whether all our Javascript libraries and open source Javascripts were indexed correctly. Double checking that is what actually triggered the unknown component notification because we weren't 100 percent sure what it was. They then talked us through how to handle those. I'm happy they reached out to do the review. A lot of times, after you buy a piece of software, you just cost the vendor money every hour that they spend on you. In this case, the review was offered and initiated by them. We really appreciated that and we have had good experiences with them as a company.

It has been fun to work with Sonatype. We have been happy with them as a company.

We were using a product before and weren't super happy with it. I found this solution through an Instagram ad. I don't even know how it popped up there, but it was an ad on Instagram that was from Sonatype about one of their free publications that you could get about issues in DevOps. After that, we talked as a team, decided to check it out, and that's how it happened. As annoyed as I've been by those Instagram ads, this one actually worked out very well for us. I guess for Sonatype too.

We used a different enterprise solution (Palamida/Flexera) previously which was a bit cumbersome to run. It would only check when we manually triggered it. Previously, because the scan was sort of deferred, you would find out a month or two later (or whenever you did the scan) that the library might have an issue. Then, we would have to find an alternative library. However by that time, you've already used it and have to refactor what you were doing before. A refactor like this will take time away from our developers and testers and also will require a redeploy. The process now is a lot smoother because the scan is done automatically and immediately after each build, so we get feedback right away.

Additionally, with the plugin for our IDE that Sonatype provides, we can check whether a library has security, quality, or licensing issues very easily. Which is nice because Googling for this stuff can be a bit cumbersome. By checking it before code is even committed, we save ourselves from getting notifications at all.

Nexus IQ Server integrates well with our other ecosystem. Palamida required us to run it locally, like physically, because they would send you the hard drives that had all the mappings on it. These were used to index the components our software is using. We had trouble trying to figure out how to keep it up to date because they would have to send this to us every couple of months or so. Whereas now, we're running IQ Server in AWS and it actually connects to Sonatype's own service for updates. These live updates are a huge improvement to what we were using before.

Releasing a new version of our application used to take between three to six months. What would happen is before we would release it, that's when we'd do a scan and see if there was anything that we needed to fix. We have had it where enough issues came up where we're like, "We need to decide should we still release this or continue trying to work out all these different issues, then release it?" This would push back the release by two to four weeks. Now, because it's a continuous process and we can evaluate new components early on, it doesn't mess with that timeline so much. We know what the status is already at this point. If something comes up, then we can address it right away instead of having to do it near the end. It has helped us to solidify timelines a bit. Because of it, we have not had a delay in a release due to unknown security issues that we found near the end of our version release cycle.

On June 26, we got our license key for it. It was a week or so to get the whole thing up and running, from getting license keys to telling our IT department to set up the VM and install it, and then logging in to configure it.

The initial installation was rather straightforward. It was easy for me because we have a system administrator who takes care of it. But he did not report having any problems installing it. He had to also set up a database, then figure out some of the networking stuff, as sometimes the connectivity with the cloud services behind a VPN gets a bit tricky. But all in all it was fairly straight forward to integrate it. Once in the same virtual network, our VMs, Bamboo service, and Jira talked to each other and didn't have any issues. Installing updates has been straightforward as well.

Obviously there's a learning process that starts when you first log in. But things are pretty easy to figure out. Besides that Sonatype's support has been very good. They showed us how to use it immediately after installation, and they followed up some time later to see how we've implemented using it. They had some very useful tips and pointers at that time too. We've been impressed by their user support.

We had a call with the Sonatype team and they talked us through the setup. Their assistance with it was really good. That may have mitigated any complications that we would've had. As far as I'm aware, even the installation of the application was easy.

The DevOps stuff is a combo between the system administrator and developers. After he does all the VM and networking setup, we do the configuration from within the application once it is ready. I did some of the integration with Bamboo, then another developer set up the integration with Jira. I'm sure there are plenty of people who have the skill set which covers all those things and would be able to do the deployment with just one person. 

All our system administration is done by a company called Infidati. We've been using them for a long time, about five to six years and our experience with them has been excellent. They are fully remote, my immediate boss is the only one who has met people from their company. We mostly communicate with them through their email ticketing system. They're an easy, wonderful company to work with that has great response times.

This product was cheaper than the one we were using, so that is a direct savings. Though, it's hard to estimate time saved.

There is definitely a lot less frustration with it, because we had some frustration earlier with the last product. Some of the frustration that we still have was trying to find an updated version of the library, which is not really Sonatype's fault. That is just how open source software works. However, there is definitely a lot less frustration with a lot more clarity about what exactly we're looking at and what the step is needed to get rid of the vulnerabilities that we do find. It's hard to measure the impact of reducing developers' frustration, but I think we can all agree that having happy developers is good for a company!

Another thing that's hard to measure is the positive impact on company image. We get security questionnaires from potential clients, which will ask how we detect and address security issues. In our industry, what is that worth to a health system that houses patient information that we continuously monitor for security vulnerabilities? And that we are able to address these concerns as soon as they come out? It's a marketing thing and it's hard to quantify what that's worth, but we know in healthcare these things are definitely valued and appreciated.

In addition to the license fee for IQ Server, you have to factor in some running costs. We use AWS, so we spun up an additional VM to run this. If the database is RDS that adds a little bit extra too. Of course someone could run it on a pre-existing VM or physical server to reduce costs. I should add that compared to the license fee, the running costs are so minimal they had no effect on our decision to use IQ Server.

The license fee may be a bit harder for startups to justify. But it will save you a headache later as well as peace of mind. Additionally, it shows your own customers that you value security stuff and will protect yourselves from any licensing issues, which is good marketing too.

We did not evaluate other options. Though, we did compare it to what we were using. When we looked at what Sonatype did and how it was able to run in the cloud, we were eager to give it a shot. We honestly didn't do extensive research into other alternatives. We knew we wanted to switch from what we were using rather quickly and Sonatype's response time was very good.

Do it as early as possible. You will have to clean up sooner or later. I remember when we fired it up it immediately found things that the last solution didn't find. This made sense after we realized that IQ Server gets continued updates and our last solution was just getting updates whenever we were able to get new hard drives sent to us. Our first scan popped up with a number of high vulnerability and security issues. At that time the Sonatype people were on a call with us to help us out setting it up. We asked them if seeing this many alerts was pretty average and they told us it was pretty normal in their experience. So that's when the cleanup started.

Our awareness of how many of these open source libraries have things that you got to watch out for has increased a lot. We would find some stuff out through our previous solution, but sometimes it was unclear exactly how serious it was, where it came from, or how to fix it. Additionally we've gotten a lot better at manual dependency resolution, because sometimes the problematic version of a component you're trying to eliminate is a transient dependency. so you have to figure out which alternative version you can use and then tell the top level dependency to use that instead.

None of our people who went to college to learn how to write software or do Java certification remembers ever getting a class on how to deal with these kind of things. Nobody remembers taking a class where they warn future developers: "You're going to have licensing issues that you will need to solve. You will need to do dependency resolution and be asked to mitigate security issues in this stuff as you use it." But this is actually a pretty important aspect of proper software development. Our team already had this awareness, but now it is now something we can also easily check. It is a continuous part of our sprints to check and handle notifications of these security issues. We've had to learn a lot more about how to fix transitive dependencies.

While we don't have integrations directly with our version control systems, we do integrate with our continuous integration service and ticketing system. We use a host of Atlassian products: Jira is one of them and Bamboo is another. You can use this solution to automate open source governance and minimize risk. E.g., we could have a build fail when it finds security issues, but we have not done that for our development and test environments as of yet. The solution also integrates with things like user directories.

We did look through the default policies. We also received some help from Sonatype to go over them. As a default, the security policies were good. Therefore, we decided to stick with them.

I would give the solution between an eight and nine (out of 10). If there was a way to easily see where a transient dependency is pulled in from, and if Sonatype would add a few more of the repositories that we pull dependencies from, then I'd probably give them a 10 (out of 10).