Sonatype Lifecycle Reviews

Our primary use case is preventing major security vulnerabilities.

We use it as part of build our pipeline. We have a plugin that gets scanned by Sonatype as the build runs and it scans for all third-party dependencies. We haven't yet gotten to the point where we fail a build, but we make the matrix visible so we know where we need to focus. In the coming months, we plan to actually start failing builds and preventing releases which have certain vulnerabilities, from going into production.

One of the ways it has improved the way our organization functions is that it has created awareness of unlicensed, third-party dependencies and insecure vulnerabilities. That's what it has done at the moment. It's going to have a bigger impact when we start enforcing it on the build pipeline. Then they will be at a point whereby they have to conform to the policy.

There are a number of open-source components that it has highlighted. It means that we have to find a replacement for them. There's a recommendation that's given when it highlights them. So we can remain in the same open-source components, it's just that there has been a patch or an update to them to close off vulnerabilities.

In the context of remediation costs, there is the issue of reputation if you are not releasing secure apps to market. That's one major problem. Secondly, if you know you're releasing insecure applications, you're incurring technical debt because you're going to have to, at some point, mitigate those security vulnerabilities.

It's become a mandatory control now. We just went through a process of defining all the DevOps controls, and one of those controls is to use Nexus IQ. They can't skip that part of their build pipeline. Every code has to be scanned.

There are a number of features that we find valuable. The basic functionality of Sonatype is its scanning feature. Out of that, you get the reporting capability as part of your build and it gives you the statistics as part of the build report.

There's also a feature whereby, in your IDE, you can get immediate feedback as you're developing. That's also quite a handy feature.

In addition, in our Nexus repository - we have Nexus OSS and Nexus Lifecycle linked together - all our third-party dependencies are scanned.

The policy management is quite federated, in a sense, whereby we can assign a policy specific to an application.

The grandfathering mode allows us to add legacy applications which we know we're not going to change or refactor for some time. New developments can be scanned separately and we can obviously resolve those vulnerabilities where there are new applications developed. The grandfathering is a good way to separate what can be factored now, versus long-term technical debt. In most cases, these legacy applications are simply retired, so to refactor them wouldn't make sense. Most of them go through a rewrite cycle or are replaced by something we have purchased.

There's a very interactive view where there's a recommendation, as part of the reporting. You can click on a certain vulnerability and it will give you a recommendation. For example, if you're using something that's not licensed or has a certain license type, it will recommend to you, "You should go onto this license," or, "Go to this version, which covers this vulnerability." There are actual recommendations that are synchronized with the database in the States.

The solution integrates well with our existing DevOps tools. We're using Atlassian and using Bamboo as part of that Atlassian set. Bamboo is our continuous integration tool. There's an out-of-the-box Nexus IQ plugin for Bamboo. It's really simple to configure and it gives you results as you're building. Also, the API is very rich, meaning that we don't necessarily have to get a report from the front end. We can build custom reports through the API.

They have recently released some online training documentation, because we had to a lot of our own learning. If they had a more comprehensive online tutorial base, both for admin and developers, that would help. It would be good if they actually ran through some scenarios, regarding what happens if I do pick up a vulnerability. How do I fork out into the various decisions? If the vulnerability is not of a severe nature, can I just go ahead with it until it becomes severe? This is important because, obviously, business demands certain deliverables to be ready at a certain time. So, some online tutorials around the administration, around developers, on how to use the tool effectively, would be a good idea.

Where we have extended is that we're using third-party Docker containers. So, we're not just using third-party libraries, but we also have third-party-type Docker containers, or containers from Docker Hub, for example. Somebody else has built the Docker image and we're using the Docker image. Scanning of security and vulnerabilities on that image, specifically, would be useful. It would be good, as we're building an image, or as we're running an image, if we could decompile that image and scan it, to look for any vulnerabilities or any areas where there's been a violation of licensing. For example, we could download a WebLogic container, which could be an infringement of licensing. It's things like that which our developers need to be mindful of. They could simply download any container from Docker Hub, without being aware of the licensing violations or the security vulnerabilities.

The stability is very good. It's extremely stable. We haven't had an instance where it's running out of memory or anything else.

We haven't had an instance where we have run into such high volume that we needed to scale. The only change we made was to increase memory, because we started utilizing the API. In terms of redundancy, all the data is sitting in the database. We have backed up the folder structure, and the worst case is we just restore that folder structure onto any server. You could run it in Docker if you wanted to, as well so that is immutable. It's been made to be a lift-and-shift type of product.

We have 100 users actively using it at the moment. They are developers, mostly.

We haven't had an instance where we needed to call tech support. There haven't been issues to the extent that we needed to get hold of tech support. Most of it we deal with in-house. The last issue was probably a year ago, where we ran out of memory and that was a simple config change.

We did not have a previous solution. We brought on Nexus Lifecycle because there has been a heightened, more aggressive stance on security.

The initial setup is pretty straightforward, both the installation and upgrades. We're running it on a Linux environment, so there's not much that we needed to do there. 

Policy management is probably where it gets a bit complex. That's where I referred to the need for some tutorials, some more comprehensive documentation.

The initial deployment took less than an hour. It's very quick. Download it and run the .jar and you're good to go. We do use an Oracle Database, so we did need to set up the database. We just pointed it to one of our Oracle instances.

The implementation strategy was to start enforcing the policies and, eventually, to prevent things. We are implementing it in such a way that the developers will, at the point of development, in their IDE, be faced with these warnings that they are using insecure, third-party dependencies and where they are violating the licenses. That's the strategy, whereby we simply block such releases from getting into production. That's where we aim to get.

For deployment you literally just need one person. For maintenance, we have just two people, and that's for an entire pipeline. They're automation specialists so they provide automation solutions. They also act as application administrators.

We haven't seen ROI as yet, simply because we haven't been harnessing the full potential of the tool. The way I think we will potentially see a return on investment is if we are using any licenses that could be costing us indirectly. We could be looking at certain technical debt which we could be dropping. Those are the aspects we could look at, but we haven't yet maximized the true, full capability.

Our licensing is bundled. We pay a single licensing cost for both Nexus OSS and Nexus Lifecycle together. So I'm not sure what the individual costs would be. We bought both Nexus Repo - we're using Nexus 2.0 and Nexus 3.0 - and Nexus Lifecycle.

There's SonarQube which does static code analysis, but not at the level that Nexus IQ offers it. There is Artifactory, which does do Docker scanning now.

One thing that Nexus IQ has been able to do is to be almost proactive in its integration. You can be in your IDE, you can be in the build pipeline, you can be in the Nexus Repository, and you can get a view of the vulnerabilities. Also you can get recommendations, so you don't necessarily have to waste time in searching the web for a patching solution or an update to fix the vulnerability. It actually gives you recommendations about what you can do to mitigate the problem. That's a distinguishing feature from the other toolsets.

Have a key, a defined goal because, as much as the tool is there, it isn't able to create a goal. The goal is, "We would like to improve the security of our codebase by at least X percent, ensure that 90 percent of our applications, for example, going to market are secure applications." With that goal in place, I would look at purchasing the tool because it would be an immediate implementation of that strategy. We bought the tool with that idea in mind, but nothing clearly defined on a granular policy level. But that's ultimately what makes the difference, to say we are focusing on looking at these types of either licensing or dependencies. The tool is then just automating that process or enabling us to do that. It's taken us about two-and-a-half years to implement a strategy. Whereas, if we had the strategy initially in place, it would have gone much faster.

The governance is centered around security and licensing. Those are the core governance factors around the policy. From a dev SecOps perspective, it's fundamental for governing your third-party dependencies. That's where the enforcement comes in. Once you've defined the policy, it becomes the law, and you can enforce that law. If you are working in a SecOps-type environment then you would sign off on that policy to enforce that.

We haven't used the Success Metrics to its full potential. We understand it revolves around targets that need to be set and how far you are from those success targets, but we haven't used that as yet.

I wouldn't look at it as a root-cause analysis or a monitoring tool. Yes, it does scan for security vulnerabilities and where we've violated licensing, but it's not used as an Elasticsearch, a Splunk-type, or Dynatrace-type of tool. When it comes to troubleshooting and root cause analysis, will we use our Dynatrace and our Elasticsearch to look at the logs.

A lot of the third-party dependencies are open-source dependencies. A lot of them are provided through Apache, etc. We always look at enterprise solutions because of the nature of our business, but where the is an open-source piece of software which we can utilize as part of our enterprise solution then we do. We haven't scoped Nexus IQ to focus on open-source software. Nexus IQ in and of itself is commercial. If we had to use Jenkins or any of the open-source build tools, it would easily integrate with those open-source tools.

Using Nexus Lifecycle, it might end up taking longer to release to market because you may need to refactor. In an industry where these applications have already been developed and now you end up scanning them and you pick up all these issues, you are going to have to refactor them. That means that either new requests must go into a backlog or you fix technical debt, which is what Nexus IQ is going to tell you to do. It might have an adverse impact at first, but the goal is to get to a point where you break even. 

Now we are at a point whereby our apps are being released into production as secure applications. There is the opportunity with new applications, from the onset, to ensure that they are released as secure apps into the market. That doesn't mean that they might be released faster because that could depend on a number of factors. It could depend on your testing cycle, it could depend on your release process, etc.

We haven't had a one-on-one sit-down, or a survey done to really gauge the type of developer engagement. Our level of adoption has been a little inconsistent. Right now, they're getting the visibility of these metrics, but they don't actually have to do anything about it. But once we enforce the policy that their builds and releases will fail, then they will be forced to do something about it. From a SecOps perspective, it enables them to put that application on a risk register and say, "Listen, we need business to focus on fixing this application, making sure it's secure." That's the direction we are currently headed in. Developer productivity could be based on how automated our pipeline is. We are there. We just have to focus on dev and nothing else. This might actually give them that awareness.

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 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 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.

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.