Application Security Jenkins Reviews

Showing reviews of the top ranking products in Application Security, containing the term Jenkins
Veracode: Jenkins
Sebastian Toma says in a Veracode review
Engineering Security Manager at Nextiva

Scalability is the main issue with Veracode. For my company, the outlier is out there, but when it comes to scalability, we had issues with automatically scanning springboard artifacts. If you scan the artifacts, they want the artifacts to be packaged in a specific way. This is very well documented on the website but it's not the way we're doing business. 

The workaround was taking the build that was getting put together by Jenkins and moved through the environment. We had to make a separate one, packaged differently just for the tools to work. For the scans to work, if that makes sense. Maybe we are just weird in the way we package our artifacts but maybe many are having the same issue.

We have about 200 engineers that have user roles in the solution. There are different roles. We have security administrators. We have team leads. We have managers. Their roles are all very well put together. Each team has a manager that has access to more features than the rest of his team. They can create things, delete things, compared to the regular guys that can only see the reports. It's very well structured, from that standpoint.

Theoretically, everything is integrated with Jenkins, so the staff depends from one application to another, i.e. three people or eight people from our side. From their end, in our pricing model, we have access directly to an account manager. They have a team of engineers that usually help us if we encounter any issues. It's very extensive in use. We have about 80 services and applications going through using the scanning solutions that Veracode has and we are scaling up.

View full review »
Divakar Rai says in a Veracode review
Senior Solutions Architect at NessPRO Italy

The initial setup was straightforward. What I recall is that it was not really difficult and we had optimal support. They also provided us with documentation to help set up integration with tools such as Jenkins.

View full review »
reviewer1436241 says in a Veracode review
DevSecOps Consultant at a comms service provider with 10,001+ employees

We use the Veracode SAST solution to scan the Java, Node.js, and Python microservices as part of our CI/CD pipeline, wherein we are using our CI/CD server as Bamboo, Jenkins, and GitLab CI/CD. 

We have teams for both our cloud pipeline and on-prem pipeline, and both teams use this solution. We are using Veracode to constantly run the internal application source code and ensure the code's security hygiene.

View full review »
Acunetix Vulnerability Scanner: Jenkins
Senior Security Engineer at a media company with 1,001-5,000 employees

At the current pricing structure, I would tell people to do their research. If you have X amount of dollars to spend in the budget, and you're looking for a good solution, definitely consider Acunetix, but also consider other tools for similar features and functionalities where you may get a little bit more bang for your dollar, frankly, versus a tool that's still maturing as it's starting to take market share. Acunetix is a very intermediate tool. It's not an advanced DAST solution. It's still in its infancy. There's a lot of the solution to still build out, a lot of features to still work on, but it is definitely a tool that's worth looking into. Keep in mind, for that same price structure, you can get more established, more brand-name solutions.

The speed of the solution is about average. I use a lot of DAST solutions and I can't say that I'm blown away by the amount of time it takes to complete a security assessment, but I do like that it's not slow. It's not the fastest tool I've ever seen, but it's not the slowest tool I've ever seen, so it meets my expectations. It is a fast application but I'm not blown out of the water by it.

It definitely meets the benchmark. Like I said, it doesn't fall below expectations. When you're running Acunetix against a site, looking for security vulnerabilities, you're not blown away by the speed, but you're not sitting there for a day-and-a-half waiting for results or waiting for a scan to complete. It really depends on the size of the application and the granularity of that application. Acunetix performs just as expected. It's not a bad thing. 

We have very large applications, so it could be less about the solution and more about the depth of our applications. A lot of our applications have special prerequisites that Acunetix just can't expect or predict. A lot of it is giving Acunetix the proper permissions and things of that nature to go in-depth with DAST scans. On average, depending on the application, it can take anywhere from six to eight hours.

We host Acunetix on our own environment. I don't think they have a SaaS solution yet. We host it in an in Azure environment where we put it on our own server - a dedicated server - specialized to doing DAST security scans - and we are happy. We're not unhappy with Acunetix, but we're not greatly excited that this is the best tool ever. But we are very impressed by some of the things that it has been doing. It's that middle ground. It's a good tool. I would definitely recommend it.

The remediation rate is based on the maturity of our development team. Acunetix doesn't provide a format that makes remediation easier. It does what every tool does and gives us the vulnerability, explains the vulnerability, and gives us some remediation guidelines or tips, but that's what everyone does. So it really depends on the workload of our development team, and what backlog they have or what their sprints look like going into the next cycle. It has very little to do with the tool and more to do with the capability and workload of the development teams.

Using it on a secondary basis, we have found some medium vulnerabilities but no critical vulnerabilities which required immediate remediation. What I do notice about Acunetix is that there's a lot of "white noise," a lot of "background noise," things that just don't apply. When filtering those out and removing the false-positives that don't apply to the actual application, we may find one cross-site scripting. That may be a medium vulnerability but not a high vulnerability because of business impact. There are different risk ratios that we apply to different findings, but we haven't found anything critical with Acunetix. It could just be that we don't have any critical vulnerabilities in that environment - although I don't think that's the case. In terms of DOM-based cross-site scripting vulnerabilities, it all depends on the application.

We don't have it deployed on any Linux server. It's on our Windows environment. We have it in Azure, in a cloud, so it's a Microsoft framework that we have Acunetix installed on top of.

All of our users of Acunetix are in development and security roles. The number of users is well into the hundreds. I administrate the tool, I set the roles and also manage users and user interface and interaction. We have a dedicated server team that does maintenance and deployment. If we need to deploy another instance of Acunetix, that is usually done by our server team. They handle all server infrastructure activities. I am the senior security engineer, so I handle all security-related activities.

We don't have plans to increase our usage of Acunetix. We may stop usage. Acunetix is raising the cost of licensing. It's 3.5 times what we were initially quoted. As a secondary solution, we're trying to figure out, is it worth the extra cost just to have it do some supplemental scans for us. We're still evaluating that.

Overall, Acunetix is definitely a seven out of ten. I like the product. It's doing a lot of what its competitors are doing. It's running great DAST scans and it has a rich database of vulnerabilities that it can report and it also provides a web component of its solution where you don't necessarily have to sign on to a physical server or a virtual device to interact. You can, but you can also contact Acunetix through a web interface, which is great. But the interface, in general, is still very simplistic, which may be a good or bad thing. The reporting could be a little bit better. When ending a scan I would like to see more graphical representations, maybe trends from scan to scan, of how the overall maturity is going of the application project that it's scanning or assessing. The reporting is okay. It does give you the option to do PDFs or CSVs. More reporting formats, like an Excel format, maybe an XML format, would be great.

Integration into other tools is very limited for Acunetix. While we're trying to incorporate a CI/CD process where we're integrating with JIRA and we're integrating with Jenkins and Chef, it becomes problematic. Other tools give you a high integration capability to connect into different solutions that you may already have, like JIRA. All findings that Acunetix happens to run across could be sent straight to JIRA. That would increase our remediation rate because it's very seldom that developers read PDFs of security vulnerabilities. One of the things that Qualys does is allow us to integrate into our JIRA environment, into our Jenkins environment, etc. We haven't seen the same capabilities with Acunetix. 

Because of these things, I have to give it a seven. It's ultimately a great tool, a great scanner, and you can really rely on some of its findings once it's tuned.

View full review »
Senior Security Engineer at a insurance company with 10,001+ employees

It is a pretty good product.

Do a demo and test whatever application that you are using right now. If you have a site where it is more difficult to identify vulnerabilities, or you have issues scanning, use this to check your particular software. If it can handle your more challenging apps, then it will definitely handle the easier, less technical sites. 

We view it on a very traditional PC. Aesthetically, you can see what you are looking for. Unfortunately, we don't utilize the dashboard as much as we should and take full advantage of it. Right now, we're pretty much in the infancy of building the solution. It's nice to be able to look at the dashboard and see the vulnerabilities which are there. However, at this time, we not doing the retesting with the scans to clear them out. So, we are not taking advantage of this feature.

We are looking to increase the usage of the product to do multiple scans. We will potentially be increasing the number of applications that we are scanning. We are also looking to add the AcuSensor piece with our Jenkins Pipeline, but we haven't gotten there yet.

View full review »
reviewer1218672 says in an Acunetix Vulnerability Scanner review
IT Manager at a financial services firm with 1,001-5,000 employees

I would recommend the product. It's very easy to integrate with Jenkins, with ALM. The most important element for us is that it's very easy for developers to use. They don't need to have any knowledge about security, threats or anything. They just run the tool against their application, and that's it. They get the results.

I would rate this product a seven out of 10.

View full review »
Checkmarx: Jenkins
Don Robbins says in a Checkmarx review
Software Configuration Manager at a tech vendor with 501-1,000 employees

One of the biggest heartaches that we have is that all of our Windows servers are on an automated upgrade. Whenever Windows upgrades, we lose the order of the ciphers and it brings down the Checkmarx webpage. 

Our company policy is that we upgrade our servers at a minimum of once a month, if not more. It's a hassle to keep up on that. The ciphers are such a pain to manage.

To set up a cipher connection, there's a tool out there called IIS Crypto. We just run that tool to set the best practices. It forces us to reboot the server. We haven't figured out how to automate the whole thing yet. 

There have been some Windows updates that haven't triggered this issue where the ciphers get messed up. The only thing we're running is TLS2. At that higher level, everything is just a pain.

All of our servers are built out through code. In other words, we use Ansible and Jenkins to automatically create machines. Everything is virtual these days. It's either virtual in-house or virtual in the cloud. 

The issue with Checkmarx is the next pain point, i.e. their installation procedure is GUI-based. They've got a command line for upgrades. I haven't seen the command line for the initial install.

My last statement on Checkmarx is Windows would not be my choice for any kind of server implementation. I'm not a Windows fan at all. Every other tool in our company is Linux-based and our target systems are Linux as well.

I don't have the experience and the knowledge of working on a Windows system compared to my Linux knowledge. Checkmarx being Windows only is a hindrance as well.

Another problem is: why can't I choose PostgreSQL? I would like to have an additional feature added to the product to support either PostgreSQL or MySQL. Those are the two free databases that are enterprise-ready.

View full review »
reviewer971370 says in a Checkmarx review
CEO at a tech services company with 11-50 employees

The initial setup is pretty simple, it's no problem to start using Checkmarx. It's a very good approach if you compare it with competitors.

It only takes a few hours to tune your Checkmarx solution. You may need more time for deeper integration when it comes to DLC integration, for example, when using plug-in build management, such as Jenkins

If you are scanning and you have the source code then you are good to start scanning in a few hours. Three to four hours is required for tasks done in source code.

We have one or two engineers who can work with the solution.

For some of our customers have more than 100 developers and a DevOps team.

View full review »
SonarQube: Jenkins
AppSecAn0945 says in a SonarQube review
Application Security Analyst at a agriculture with 501-1,000 employees

I would suggest trying the product. I like its useability because it has a simple approach.

We use this solution in conjunction with Jenkins, and we have a two-week deployment cycle.

I would rate this solution a seven out of ten.

View full review »
Jeff Ingalls says in a SonarQube review
Automation Tool Specialist at a comms service provider with 1,001-5,000 employees

This solution is part of our pipeline. We use GitLab for source control and Jenkins to build management. Jenkins kicks off our SonarQube scans, we use Checkmarx for static code analysis, UrbanCode Deploy, and UrbanCode Release.

Using SonarQube has helped us to identify areas of technical debt to work on, resulting in better code, fewer vulnerabilities, and fewer bugs.

View full review »
Hervé KAMDEM says in a SonarQube review
Country Manager Senegal at a financial services firm with 10,001+ employees

This initial setup of this solution is not basic, but it is not complex. If you have some experience in IT then you should be able to do it.

We have this tool integrated with Jenkins.

One or two days is enough for deployment. There is some configuration to do, which takes time, but it is not difficult to deploy.

Three or four staff are enough for deployment and maintenance.

View full review »
Kiran Gujju says in a SonarQube review
Cyber Security Architect (USDA) at a government with 10,001+ employees

The most valuable features are the dashboard reports and the ease of integrating it with Jenkins

View full review »
Yash Brahmani says in a SonarQube review
Devops Engineer at a financial services firm with 10,001+ employees

The most valuable feature is the security hotspot feature that identifies where your code is prone to have security issues.

It also gives you a very good highlight of what's changed, and what has to be changed in the future.

Apart from that, there are many other good features as it's a code analytics platform. It also has a dashboard reporting feature, which is very good. I also like the ease of its integration with Jenkins.

Another valuable feature is the time snapshot that it provides for the code. It provides the code quality, the lagging, and the training features like what already has gone wrong and what is likely to go wrong. It's a very good feature for a project to have a dashboard where the users can find everything about their project at a single glance.

View full review »
Coverity: Jenkins
reviewer1419987 says in a Coverity review
Senior Technical Specialist at a tech services company with 201-500 employees

The most valuable feature is the integration with Jenkins. Jenkins can be used to automatically run it to perform the code analysis.

Integration with GitLab is helpful.

View full review »
WhiteSource: Jenkins
reviewer1250697 says in a WhiteSource review
User at a tech vendor with 1,001-5,000 employees

Our primary use for WhiteSource is security and license risk detection in open-source, third-party libraries and components. We run scans from multiple source control and build systems (TFS, ADO, Jenkins, ...). Some of our scans are automated, while others are done manually with the unified file agent in offline mode scan, and then the resulting "wsjson" file is uploaded to the WS SaaS portal.

View full review »
Sonatype Nexus Lifecycle: Jenkins
ManojKumar9 says in a Sonatype Nexus Lifecycle review
Systems Analyst at Thrivent Financial for Lutherans

We have reduced a lot of security access issues. For example, we can restrict user access level for the baseline of our organization's security.

Right now we are using it in Jenkins, it's open-source and it has very good restrictive policies. We are now moving into Bamboo. It has not been completely implemented in production, but we have started on it.

View full review »
Charles Chani says in a Sonatype Nexus Lifecycle review
DevSecOps at a financial services firm with 10,001+ employees

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

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

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

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

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

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

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

View full review »
Axel Niering says in a Sonatype Nexus Lifecycle review
Achitekt at SV Informatik GmbH

The most valuable feature is that I get a quick overview of the libraries that are included in the application, and the issues that are connected with them. I can quickly understand which problems there are from a security point of view or from a licensing point of view. It's quick and very exact.

The onboarding and policy grandfathering are quite useful, to keep in mind what we have already discussed around parts of the application, and to identify our own parts of the application which are not discovered by Nexus Lifecycle.

The data quality is really very good. We have also checked other products and they do not provide such good quality data. Still, we must look very closely at a single vulnerability from a single issue. We have to understand what problem it's indicating. However, without this tool there would be no way to do this. The data quality is really very good.

It was very easy to integrate into our build pipeline, with Jenkins and Nexus Repository as the central product. It was very easy to integrate the evaluation of the application to be built into the Jenkins process so that we had the ability to check how good the application is thus far. It also helps when you look at the stage we are at in building this application, whether test or production.

View full review »
ConfigManag73548 says in a Sonatype Nexus Lifecycle review
Configuration Manager at a health, wellness and fitness company with 5,001-10,000 employees

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.

View full review »
Sebastian Lawrence says in a Sonatype Nexus Lifecycle review
Solutions Delivery Lead at a financial services firm with 201-500 employees

We have increased the digital footprint of our company over the last few, extensively. We have extensive open source development happening which depend on open source components. Using the scanning with Nexus IQ, a lower count of false positives has helped us roll out our security policies across the development cycle and ensure that our deployments to production are as secure as possible. This helps us avoid critical vulnerabilities being exposed onsite. It saves us time in any remediation activities that we may had after deployment, because if we had discovered security issues after the application was completely developed and deployed, it would be more difficult to go back and make changes or put it back into a cycle. Then, we would have to shift to multiple outcomes due to business expectations, member expectations, and our client expectations. Bringing it back into the development cycle would take a lot of time. Attaching it to the development cycle and by integrating Nexus IQ into our plans, we have a policy that will not allow vulnerable artifacts to be deployed to production. This forces it to be handled during the development cycle.

The solution has increased developer productivity when remediating issues, as the issues are clearly laid out. We are saving five to 10 percent in developer productivity. 

This solution integrates well with our existing DevOps tools. We use it in our Jenkins build pipeline. If the Nexus IQ scan fails, then it produces an error that fails the build. When a developer builds on their machine, as well, it flags issues and lets them know which component has a problem.

This solution brought open source intelligence and policy enforcement across our SDLC (software development lifecycle). The enforcement is simply because the build pipelines use Nexus IQ, then it fails when Nexus IQ has an error and identifies a component with multiple security issues because it breaks the release pipeline. The enforcement is there because you can't release anything without going through that pipeline.

View full review »
reviewer1268016 says in a Sonatype Nexus Lifecycle review
IT Security Manager at a insurance company with 5,001-10,000 employees

The key feature for Nexus Lifecycle is the proprietary data they have on vulnerabilities. The way that they combine all the different sources and also their own research into one concise article that clearly explains what the problem is. Most of the time, and even if you do notice that you have a problem, the public information available is pretty weak. So, if we want to assess if a problem applies to our product, it's really hard. We need to invest a lot of time digging into the problem. This work is basically done by Sonatype for us. The data that it delivers helps us with fixing or understanding the issue a lot quicker than without it.

The solution integrates well with our existing DevOps tools. We have a few different ways of integrating it. The primary point is the Jenkins plugin to integrate it into the pipeline, but we also use the API to feed applications from our self-developed systems. So, the Sonatype API is very valuable to us as well. We've also experimented with IDE plugins and some other features that all look very promising.

View full review »
Scott Hibbard says in a Sonatype Nexus Lifecycle review
DevOps Engineer at Guardhat

We have it running on the majority of our builds for all of our applications and we use Jenkins for our build system. Eventually, the goal is to incorporate this into Jenkins so that if we don't get a good enough result on both Nexus IQ and SonarQube, we'll actually fail the Jenkins build. That way we force ourselves to maintain good metrics on both of them. So Nexus IQ is making sure that we're using dependencies that don't have known vulnerabilities. And SonarQube is making sure that our code maintains a certain level of quality.

Unfortunately, we haven't been able to take full advantage of Nexus. It's set up and it's working, but we haven't rolled it fully into our development process. Our builds use it, but we're not using the information from it a whole lot. The solutions are running, but we're not enforcing the results from them and, therefore, our developers aren't driven to make absolutely sure that they are going well. Hopefully, we'll get there soon.

View full review »
Wes Kanazawa says in a Sonatype Nexus Lifecycle review
Sr. DevOps Engineer at Primerica

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.

View full review »
Michael Esmeraldo says in a Sonatype Nexus Lifecycle review
Sr. Enterprise Architect at MIB Group

We have a lot of legacy applications here and they're all built with Ant scripts and their dependencies come from a shared folder. There's not a lot of "accountability" there. What we get out of using Nexus is that all of our dependencies are in the same place and we can specify a specific version. We no longer have a situation where somebody has pulled down a .jar file and stuck it in this folder and we don't know what the version is or where, exactly, it came from. That's one of the benefits.

Another of the main things we get is what Sonatype calls a "bill of materials." We can go into our Nexus product and say, "Okay, here is our ABC application. What are its dependencies?" And we can be specific down to the version. We know what's in it and, if a vulnerability gets reported, we can look and see if we use that particular component and in which applications, to know if we're vulnerable. If we find we're exposed to that vulnerability we know we need to go and remediate it.

The biggest benefit we get out of it is the overall ease of development. The ability to automate a lot of the build-and-deploy process comes from that.

The data quality helps us solve problems faster, as in the security vulnerability example I just mentioned. In those circumstances, we have to solve that problem. Previously, we wouldn't have seen that vulnerability without a painstaking process. Part of the Nexus product, the IQ Server, will continually scan our components and if a new CVE is reported, we get that update through Nexus IQ. It automatically tells us, "Hey, in this open-source library that you're using, a vulnerability was found, and you use it in these four applications." It immediately tells us we are exposed to risk and in which areas. That happens, not in near real-time, but very quickly, where before, there was a very painstaking process to try to find that out.

A year ago we didn't have DevOps tools. We started building them after I came on. But Nexus definitely integrates very well with our DevOps tools. Sonatype produces plugins for Jenkins to make it seamlessly interact, not only with the repo product, but with the Nexus IQ product that we own as well. When we build our pipelines, we don't have to go through an array of calls. Even their command-line is almost like pipeline APIs that you can call. It makes it very simple to say "Okay, upload to Nexus." Because Jenkins knows what Nexus is and where it is — since it's configured within the Jenkins system — we can just say, "Upload that to Nexus," and it happens behind the scenes very easily. Before, we would have to either have run Maven commands or run Gradle commands via the shell script to get that done. We don't need to do that sort of thing anymore.

The solution has also brought open-source intelligence and policy enforcement across our SDLC. We have defined policies about certain things at various levels, and what risks we're willing to expose ourselves to. If we're going to proxy a library from Maven Central for example, if the Nexus IQ product says it has a security-critical vulnerability or it's "security high" or it's "component unknown," we can set different actions to happen. We allow our developers to pull down pretty much anything. As they pull something down from say, Maven Central, it is scanned. If it says, "This has a critical vulnerability," we will warn the developer with the report that comes out: "This has a security-critical vulnerability. You're allowed to bring it down in development, but when you try to move to QA or staging, that warning about the 'security-critical' component will turn to a failure action." So as we move our artifacts through that process, there are different stages. When someone tries to move that component to our staging environment, it will say, "Oh no, you can't because of the security-critical thing that we've been warning you about. Now we have to fail you." That's where we get policy enforcement. Before, that was a very manual process where we'd have to go out and say, "Okay, this thing has these vulnerabilities, what do we do with it?" It's much more straightforward and the turnaround time is a whole lot faster.

Automating open-source governance and minimizing risk is exactly what Nexus is for. Our company is very security conscious because we're governed by a number of things including the Fair Credit Reporting Act, which is very stringent in terms of what we can and cannot have, and the level of security for data and information that we maintain. What Nexus does is it allows us to look at the level of risk that we have in an application that we have written and that we expose to the companies that subscribe to us. It's based on the components that we have in the application and what their vulnerabilities are. We can see that very clearly for any application we have. Suppose, all of a sudden, that a Zero-day vulnerability — which is really bad — is found in JAXB today. We can immediately look for that version in Nexus. We can see: Do we have that? Yes, we do. Are we using it? Yes, we are. What applications are we using it in? We can see it's in this and that application and we can turn one of our teams to it and get them to address it right away.

I don't know exactly how much time it has saved us in releasing secure apps to market, but it's considerable. I would estimate it saves us weeks to a month, or more, depending upon the scope of a project.

And it has definitely increased developer productivity. They spend a lot less time looking for components or libraries that they can download. There was a very manual process to go through, before Nexus, if they wanted to use a particular open-source library. They had to submit a request and it had to go through a bunch of reviews to make sure that it didn't have vulnerabilities in it, and then they could get a "yes" or "no" answer. That took a lot of time. Whereas now, we allow them to download it and start working with it while other teams — like our enterprise security team — look at the vulnerabilities associated with it. That team will say, "Yeah, we can live with that," or "No, you have to mitigate that," or "No, you can't use this at all." We find that out very much earlier in the process now.

It allows us to shift gears or shift directions. If we find a component that's so flawed that we don't even want to bring it into the organization from a security standpoint, we can pivot and say, "Okay, we'll use this other component. It doesn't do everything we needed, but it's much more solid."

View full review »
Ryan Carrie says in a Sonatype Nexus Lifecycle review
Security Analyst at a computer software company with 51-200 employees

For the initial deployment, it was in place within a couple of days of starting the trial.

We did have an implementation strategy sketched out as far as requirements for success during the PoC go. The requirements were that it would easily integrate into our pipeline, so that it was very automated and hands-off. Part of the implementation strategy was that we expected to use Jenkins, which is our main build-management tool.

In terms of the integrations of the solution into developer tooling like IDEs, Git repos, etc., I wasn't really part of the team that was doing the integration into the pipeline, but I did work with the team. We didn't have any problems integrating it. And from what I did see, it looks like a very simple integration, just adding it straight into Jenkins. It integrated quite quickly into the environment.

At this point we haven't configured it to do any blocking or build-blocking just yet. But that's something we'll be reviewing, now that we have a good process.

View full review »
reviewer1380810 says in a Sonatype Nexus Lifecycle review
Computer Architecture Specialist at a energy/utilities company with 10,001+ employees

We can automate the pipeline of CI/CD. For example, if a publication uses an open source library and it's vulnerable, then the security team will mark it in the Lifecycle suite and it can go through the pipeline without manual interaction by the developer.

I'm not a security guy but I have sat with the security team. Once you set the policies, you wont need to change them. The policies wouldn't change that frequently. It covers the needs that we have.

Using the solution we have been able to clean our environment, providing more protection for our applications. We have a more hygienic environment than before. Before using Lifecycle we were almost blind to whatever we had and didn't look into the vulnerabilities within open source libraries. Now we do.

It has helped to increase our productivity a lot, especially with Nexus Repository Manager. It is way more agile. There is no comparison between our productivity before and now.

In terms of the accuracy of the data from Sonatype, at first the teams were challenging whatever the solution provided, but they then verified with the vendor of the open source libraries or via the related community, and they realized that the data from Sonatype is something that is done carefully. It's accurate and valid data. We are now introducing a security layer for open source. Before, there was no security on open source and they did whatever they wanted but that is no longer the case. They have to fix things before deploying them. It helps them resolve issues. It works most of the time, but sometimes there are challenges for the developer in solving them.

We also use the solution to automate open source governance and minimize risk with policies. Some of our developers, although not all of them, have their own Jenkins installed and they set rules and policies. They have integrated Jenkins with Lifecycle and, whenever they push into production, it verifies they are not violating any policies. Once everything is smooth, it goes into production. We haven't formalized that process yet.

View full review »
reviewer1381962 says in a Sonatype Nexus Lifecycle review
Application Security at a comms service provider with 1,001-5,000 employees

We have it implemented and integrated into our CI/CD pipeline, for when we do builds. Every time we do a build, Jenkins reaches out and kicks off a scan from the IQ Server.

We use it to automate open source governance and minimize risk. All of our third-party libraries, everything, comes through our Nexus, which is what the IQ Server and Jenkins are hooked into. Everything being developed for our big application comes through that tool.

We have Nexus Firewall on, but it's only on for the highest level of vulnerabilities. We have the firewall sitting in front to make sure we don't let anything real bad into the system.

Our environment is your standard, three-tiered environment. We have the developers develop in their Dev and Test environments, and as the code moves through each environment — Test and a QA environment — it goes through a build process. We build each time we deploy.

We're addressing anything that is a nine and above. If it's a 10, we don't let it into our system; the firewall server stops it. If we have nines we'll let it in, but I'll tag the developers and they'll have to do a little triage to figure out if the problem that is being reported is something we utilize in our system — if it's something that affects us — and if it's not, we flag it as such and let it go. We either waive it or I'll acknowledge it depending on how much it's used throughout the system and how many different components are being built with that bad library.

View full review »
Snyk: Jenkins
reviewer1367229 says in a Snyk review
Senior Manager, Product & Application Security at a tech services company with 1,001-5,000 employees

The way they are presenting the vulnerabilities after a scan. It's very organized and easy to access. The UI is very organized. I also like that we can use the CLI or commands to run a scan locally or in the pipeline. 

The CLI feature is quite useful because it gives us a lot of flexibility in what we want to do. If you use the UI, all the information is there and you can see what Snyk is showing you, but there is nothing else that you can change. However, when you use the CLI, then you can use commands and can get the output or response back from Snyk. You can also take advantage of that output in a different way. For the same reason, we have been using the CLI for the hard gate in the pipeline: Obtain a particular CDSS score for vulnerability. Based on that information, we can then decide if we want to block or allow the build. We have more flexibility if we use the CLI.

For the pipeline, we use Jenkins, and for storing images in the build, we use Artifactory with some Jenkins integrations. This is super easy because we are using the CLI, which was one of the features that I really like because it's super flexible. You can do a lot of things with the CLI. It's easy to integrate. Same thing with the GitHub integration, Snyk provides Broker images that allow you to coordinate your internal GitHub repository with the cloud solution from Snyk. It's like a proxy.

The UI is super easy to use. I have no issues with the interface.

View full review »
Dirk Koehler says in a Snyk review
Senior Director, Engineering at Zillow Group

It is meant to be a less intrusive type of solution. It is easy to integrate and doesn't require a lot of effort. It's more a part of the CI/CD pipelines, which doesn't necessarily interfere with developers other than if there are actions/remediations to be taken. From a development impact, it's very lightweight and minimal. 

It is not noticeable for most engineers since it's part of the pipeline. If no new findings are reported, then it goes through without any signals or noise. If there were findings, these are usually legitimate findings and can be configured in such a way that they can be blocked/stopped in your pipelines or be more informational. The user has all the knobs and screws to turn and tweak it towards their use case because there may be areas where security is more critical than in other parts of the company, like development projects. 

We exclusively use their SDE tools. Our CI/CD environments are powered by source code control systems like GitLab and GitHub. BitPocket has also been integrated to some extent. There are CI/CD pipelines where we pull in Snyk as part of the pipeline, jobs, Jenkins environment, etc.

View full review »
Nicholas Secrier says in a Snyk review
Information Security Officer at a tech services company with 51-200 employees

We are using it to identify security weaknesses and vulnerabilities by performing dependency checks of the source code and Docker images used in our code. We also use it for open-source licensing compliance review. We need to keep an eye on what licenses are attached to the libraries or components that we have in use to ensure we don't have surprises in there.

We are using the standard plan, but we have the container scanning module as well in a hybrid deployment. The cloud solution is used for integration with the source code repository which, in our case, is GitHub. You can add whatever repository you want to be inspected by Snyk and it will identify and recommend solutions for your the identified issues. We are also using it as part of our CI/CD pipelines, in our case it is integrated with Jenkins

View full review »
Contrast Security Assess: Jenkins
C. Ray Mallory says in a Contrast Security Assess review
Lead Application Security Engineer at FEPOC

We have 128 users between development, test, our Jenkins automation team, and management.

As soon as other business units found out about Contrast, I was getting requests to onboard their applications and their users. I just explained to our leadership that at some point we need to look at buying more on-premise licenses or going to the cloud, because it's scaling up pretty quickly. So far, I don't see any limitations. It's scaling up perfectly for our needs.

It is being heavily used. Once the management at the VP level found out how many vulnerabilities were in the applications, all types of bells and whistles and alarms went off. From there it just started rolling downhill. It was: Let's come up with a plan of getting these remediated. It's being widely used and, because it's coming from the VP down to the directors, the managers, and the staff, it's ramping up based on interest with other teams. That's one of the main reasons why I'm pushing for us to go to the cloud.

View full review »