So you’ve got upper management buy-in for your application security proof of concept and are ready to start scanning applications: how do you make sure your proof of concept (PoC) is a success and that you demonstrate the need to progress to a full scale program. This article describes some of the lessons learned at the start of our large-scale deployment of Veracode within our organisation.
The first step is to socialise the PoC internally through word of mouth, discussion forums, and developer communities by driving interest in the availability of a new tool for developers, which will assist in the development process and produce better code.
As a pentester, it’s always a different story when we are the ones writing the report. Being on the receiving end is stressful, even more so when you throw compliance into the mix. I figured since I have been fielding questions left and right about what to do when it comes to mobile applications and HIPAA compliance, I would simply write a blog post on the topic.
No source code? No problem! That’s the motto of the binary analyst.
We at Veracode have pushed the limits of static analysis (studying a program’s behavior without running it) to automatically detect and report security vulnerabilities in our customers’ codebases. Doing binary static analysis by hand is still a worthwhile skill, however, with myriad practical uses:
- Uncovering the behavior of malware
- Patching bugs in old, unsupported programs
- Verifying a program does what it claims it does
- Looking for evidence of stolen code
- Reverse engineering protocols and file formats for product compatibility
- Realizing just how much other people can learn about your own code!
Laws concerning reverse engineering third-party …
Let’s not mince words: this rambling diatribe from Oracle’s CSO is aimed directly at Veracode. No need for a cutesy acronym; we’re the only company with true static binary analysis technology, delivered as a service. Now that we’ve got that out of the way, let’s try to cut through the rhetoric (in just over a thousand words, to boot).
The recurring theme in her manifesto is the notion that certain software suppliers are “too big to test”. It’s fine for the little guys, but not the 800-pound gorillas. Instead, software purchasers should blindly trust companies with security …
[UPDATE: Since there seems to be some confusion, the "We" in the title of this post is NOT "Veracode". The expression is a generic one intended to illustrate the attitude exhibited by many companies who like to downplay the value and/or effectiveness of technologies that they themselves do not sell. I can't believe I am having to explain this.]
Fair warning, this is a bit of a rant.
Back in my consulting days (early 2000, I’m getting old), we delighted in the fact that our web application penetration testing methodology didn’t rely on automated tools. This was completely true; …
As application inventories have become larger, more diverse, and increasingly complex, organizations have struggled to build application security testing programs that are effective and scalable. New technologies and methodologies promise to help streamline the Secure Development Lifecycle (SDLC), making processes more efficient and easing the burden of information overload.
In the realm of automated web application testing, today’s technologies fall into one of two categories, Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). SAST analyzes application binaries or source code, detecting vulnerabilities by identifying insecure code paths without actually executing the program. In contrast, …
A conversation on Twitter this morning started out like this:
@dinozaizovi: Finding vulnerabilities without exploiting them is like putting on a dress when you have nowhere to go.
This clever analogy spurred a discussion about the importance of proving exploitability as a prerequisite to fixing bugs. While I agree that nothing is more convincing than a working exploit, there will always be a greater volume of bugs discovered than there are vulnerability researchers to write exploits. Don’t get me wrong — as a former penetration tester, I agree that it is fun to write exploits, it just shouldn’t be a …
HP released a new tool called Scrawlr yesterday that can be used to identify certain types of SQL Injection vulnerabilities in a website. It was a joint effort with Microsoft and a direct response to the mass SQL Injection attacks of late.
Scrawlr quickly came under fire on the Web Security mailing list for having some pretty major limitations. Billy Hoffman et al have been quick to point out that the tool was designed to address a very specific subset of SQL Injection vulnerability — the type affected by the mass attacks — and is not …