Sonatype Nexus Lifecycle Room for Improvement

EdwinKwan
Security Team Lead at Tyro Payments Limited
We created a Wiki page for each team showing an overview of their outstanding security issues because the Lifecycle reporting interface isn't as intuitive. It is good for people on my team who use it quite often. But for a tech engineer who doesn't interact with it regularly, it's quite confusing. We did that because we got so many questions about it all the time. There are other areas for improvement. The most recent one - something I haven't shared with Sonatype yet but I intend to - is with the creating of defect tickets. The solution has something that is really useful, its integration with JIRA, and it creates tickets if there's an issue. What I thought would be really good was, from the moment we break builds, there is no way to track, from a management perspective, how we are doing. We are looking at creating tickets. The problem with the tickets, which is the where there is room for Sonatype to grow, is that there is no flexibility in terms of customizing the entries in the tickets. There are certain things they put in for you, they tell you what application it is, but what I'd really like to be able to do is say, "Fill in this field with the name of the application. Fill in this field with the name of the owner. Or set a due date to be X days from when it was raised. They don't allow that. They allow hard-coded values across everything in Nexus IQ. It doesn't work well because the tickets created depend on the use case. We would like to create these tickets and give them directly to the teams that have to look after them. We want to be able to assign them to the right person, based on the application that is used. " We are looking at finding ways to integrate with it because they don't have that. Another feature they could use is more languages. Sonatype has been mainly a Java shop because they look after Maven Central. And we have been mainly a Java shop in development. But we've slowly been branching out to different languages. They don't cover all of them, and those that they do cover are not as in-depth as we would like them to be. They don't have the same level of coverage as the main language, which is Java. View full review »
Charles Chani
DevSecOps at a financial services firm with 10,001+ employees
They could do with making more plugins for the more common integration engines out there. Right now, it supports automation engine by Jenkins but it doesn't fully support something like TeamCity. That's where they could make the most improvements. In terms of features, the reports natively come in as PDF or JSON. They should start thinking of another way to filter their reports. The reporting tool used by most enterprises, like Splunk and Elasticsearch, do not work as well with JSON. They should improve the reporting so that the format can be expanded. View full review »
Devin Duffy
Information Security Specialist at a financial services firm with 1,001-5,000 employees
Application onboarding is a little bit clunky. But I use their API for that, and their API is alright. Their documentation is pretty good but there was a little bit of a learning curve with it. Onboarding an application through the GUI is intuitive but it's time-consuming. By time-consuming I mean for huge, enterprise-level companies, I don't mean for a small organization. For a small organization, it's not going to be prohibitive, but it's for large organizations with many enrollments that the GUI becomes unfeasible. I would also like to see a separate repo for components that have been un-quarantined for specific teams to use. View full review »
Axel Niering
Achitekt at SV Informatik GmbH
If there is something which is not in Maven Central, sometimes it is difficult to get the right information because it's not found. And if you look at NPM-based applications, JavaScript, for example, these are only checkable via the build pipeline. You cannot upload the application itself and scan it, as is possible with Java, because a file could change significantly, so the applications are not found anymore. This is something that could be improved in future. Also, I have seen in Black Duck, for example, that there is also information about exploits there are known for a given vulnerability. This is something I haven't seen or haven't found yet in Nexus Lifecycle. If there is a known exploit to a vulnerability, this could be something that is useful to know as well. View full review »
ManojKumar9
Systems Analyst at Thrivent Financial for Lutherans
The only thing I can say is that sometimes we face difficulties with Maven Central. We are integrating everything with that, as a repository. If Maven Central changes something in its versions... For example, if I'm using the 1.0.0 version, after one or two years, the 1.0.0 version will be gone from Maven Central but our team will still be using that 1.0.0 version to build. When they do builds, it won't build completely because that version is gone from Maven Central. There is a difference in our Sonatype Maven Central. That is the only issue I have seen so far. If an old version is gone, it's not able to use it anymore. Is there any way we can keep the old versions in our local repository instead of in Maven Central? View full review »
Gus Orologas
Lead IT Security Architect at a transportation company with 10,001+ employees
Getting it integrated depends on your structure and how your DevOps teams are structured. The biggest thing is getting it used uniformly across all the different teams. It's more of a process issue. The process needs to be thought out about how it's going to be used, what kind of training there will be, and how it's going to be socialized, how it's going to be rolled out and controlled, enterprise-wide. That's probably more of a challenge than the technology itself. It's pretty simple to get up and running. It's not really an enterprise solution, like Active Directory, which you can enforce on everyone. It's something that's done through each little vertical. View full review »

Sign Up with Email