Application Security Code Coverage Reviews

Showing reviews of the top ranking products in Application Security, containing the term Code Coverage
SonarQube: Code Coverage
ScalaCon4d53 says in a SonarQube review
Scala Contractor at a tech services company with 10,001+ employees

Code coverage of tests is their most valuable feature. Code coverage is of no value if it's high, but if it's a low number then that's of great value to me.

View full review »
Anshuman Kishore says in a SonarQube review
Director Product Development at Mycom Osi

We use SonarQube for determining code coverage, finding bugs, and searching for security-related issues in our development environment.

View full review »
Klocwork: Code Coverage
Real Klocwork User says in a Klocwork review
TMS Product Architect with 10,001+ employees

For an improved product, we'd like to see integration with Agile DevOps and Agile methodologies. Some capability of the tool that allows us to trigger the status analysis report based on actions like regular builds. We would like to have better integration with Microsoft Agile DevOps tools. This would save us a lot of time. In addition, we also sometimes experience issues with false-positive detections - phantom issues.

For the previous version, we realized it wasn't possible to have a quick dashboard for the number of violations. A feature like business intelligence or code coverage could be included. 

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

It was roughly straightforward. We got the Contrast team on the line, our solution architect, me, and our AppSec team. We also had our system engineer and our development manager, so we had about six personnel from our side at the PoC, and we had two people from Contrast. We did a conference call and I don't remember any hiccups or problems. It went smoothly. It was painless.

The main part of the installation was making sure that our configuration, our hardware and our software stack, were complementary with Contrast.

I believe we did it all in one session, in one day, and got everything set up and working. We got everything restarted and installed to start populating the vulnerabilities into the team server. 

We thought it would take a month. We allotted a month of time to get it stood up, tested, and to do a shake out. We definitely beat that timeline. Contrast had given us a list of tasks to do before we got everybody on the phone to make sure our hardware was good, our configurations were set; that we had the proper people, proper password, proper access. They gave us all of that information beforehand. Once we confirmed that we were ready, we scheduled the call and we were able to knock everything out.

The way we rolled out Contrast to our organization was that we first started with a project that we call e-services. It has about 50 applications or sub-applications or APIs. Once we got that stood up, we went to FEP Direct which has about 70 applications.

In terms of the effectiveness of the solution’s automation via its instrumentation methodology, there are two aspects to that. On the Contrast side, we do understand that you have to instrument the application to get those vulnerabilities to report to the team server. That was fine. The lift involved on our side of the house was education. Many people who had histories with a static tool assumed that Contrast is similar to a static tool. So we had to educate our development teams, our tech teams, and our management that Contrast is not like the static tools. That's one of the reasons we have it do a Visio diagram: to show where in the process Contrast fits and how it works. Now that the teams are aware of how it works, they enjoy playing around with it. Whereas, their comparison with a static tool led to questions like, "Well, how are we going to get code coverage?"

We decided, we don't really need code coverage right now because Contrast includes route coverage. When we want to look at how much of our application is covered through a test, we're looking at the route coverage. This seems to be working great with the developers but even more so for our test teams in the QA environment. It lets them know when they run their regression tests how many routes those tests have missed, and then they go back and modify their regression tests so that those routes are included.

View full review »