Coverity and Armorize are two fairly well-known names in the software industry. Coverity is known for its static source code analysis and Armorize is recognized for its security provisioning. As of today, the two have joined forces to provide the best of both world’s under one umbrella allowing static defect testing, security assessments and their resolutions to be implemented simultaneously and earlier in the SDLC.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
“We had been working with Armorize for a while on some other projects,” said Andy Chou, Chief Scientist and co-founder of Coverity, “when we really started paying attention to them. They had this vision of bringing security testing and defect resolution in early and throughout the SDLC — an idea that makes a lot of sense but is rarely acted on.”
“One of the biggest problems I’ve seen in souce code security analysis is that companies are going about it wrong. They are forcing developers, many of which have no formal education in security, to deal with major security issues, finding defects they don’t fully understand, manage them and delete them. Our direction has always been to make security issues nearly invisible to developers, they shouldn’t be reaching outside of their comfort zone,” says Armorize CEO Caleb Sima, “security provisioning should be adapted around developers, so security defect detection comes online sooner and is less intrusive.”
Security departments are typically brought onboard to test an application late in the development cycle, meaning that many issues must be addressed and resolved on heavily-truncated timetables. As a result, vulnerabilities often pass through quality check points and enter the market under the guise of a polished application that is later found defective.
Defects after a release are vastly more expensive to repair after than during the development phase and often reflect poorly on a company’s public image. It might seem like a “no brainer” but most development teams continue to wait until the last second to get their applications secure, rather than making security efforts throughout.
So when and where should security planning really take place? “The future of software security is aimed at bringing in security testing and analysis early in the SDLC. Realistically, in the future, it could be brought in as early as the requirements phase, there isn’t a good reason why prepping for security can’t be done there,” says Sima.
“Many developers don’t have a firm grasp on security issues, which is why so many defects remain in released applications. There is a real disconnect between developers, testers and the security personnel on major software security issues. By bringing security testing to the forefront, we are hoping to spread awareness of these issues and make them less-prominent in today’s applications,” says Chou.
The Coverity/Armorize combination platform could be a nice fit for agile teams who work in sprints to get portions of an application tested for security before the entire application is built and prepped for its final testing. Having most security concerns settled prior to final testing should ease the strain on enterprise security testers, who are normally hindered by limited resources and time.
As reported in June, Coverity has built a database of common defects that also includes common fixes. The database was built into the Coverity 5 offering so when defects were found in applications, the Coverity defect database would identify them and recommend fixes. Coverity plans to offer a similar function on the security side with a database of security compromises, common causes for them and solutions. Their aim is to help developers practice strong coding habits and prevent these common issues from becoming reoccurring problems.
Like the defect database Coverity introduced, the Armorize addition will also prioritize potential issues using the same high priority, medium and low categorization. This will allow low concerns to be left on the back burner in favor of solving more dangerous vulnerabilities, hopefully saving time, effort and money as a by-product.
The final product is set to hit the market before the end of 2010.