AppSec is an enormously deep subject, but generally speaking we have to worry about:

  • Our own custom apps. Do our devs care about security? Do they follow secure coding practices?
  • Third party apps that we make available. Are there any known vulnerabilities that need patching? 0-days?
  • Third party apps that we don’t make available but people use anyway. Which employees might have uploaded data to that cloud service that was just breached?

Penetration testing

Pentesting is a great way to find vulnerabilities in applications. You can do them internally, hire a firm, or outsource it to the masses via a public bug bounty program (where you reward researchers who find bugs in your app).

Do you need pentesting?

Some regulations, like PCI-DSS, require annual or bi-annual penetration testing. While most companies aren’t forced to do formal pentesting or create a bug bounty program, the effectiveness of quality bug-hunting makes it kind of a no-brainer:

According to HackerOne, 77% of bug bounty programs uncover vulnerabilities within 24 hours.

It’s extremely important to vet your testers, though. There’s a world of difference between a commodity auditor with a few fancy certifications and zero public case studies and elite red teams known for finding high-profile vulnerabilities.

For example, an auditor with outlandish demands should raise a red flag:

My security auditor is an idiot

Source: http://security.stackexchange.com/questions/19790

If you want to learn how to be a pentester, we’ve got an excellent Beginner’s Guide to Penetration Testing for you.

Vulnerability scanners

In addition to manual pentests, continuous vulnerability scanning using tools like NetSparker can also tighten up your application security by eliminating some of the tedious and time-consuming work of uncovering common issues.

But don’t think you can run continual vulnerability scans and wash your hands! Your scanner is simply your canary in the coal mine–it warns you of issues, but you have to be able to interpret the results and understand the source of the problems and how to solve them.

The bottom-line: a vulnerability scanner by itself is worth its weight in PDF reports. In the hands of a good pentester or security engineer, it can be a massive time-saver.

Source code analysis tools

Unlike pentesting and vuln scanning, static code analysis tools evaluate your app’s security without running it. Think of it as a security-spell-check but for source code (and sometimes object code).

Not a silver bullet by any stretch, source code analysis tools can be a relatively inexpensive fail-safe against developer mistakes and help improve the overall quality of your apps by highlighting general code quality issues that aren’t necessarily security-related.

It’s a best practice to integrate your code analysis tool with your build process to ensure that devs can’t deploy without running a check. Nobody will do analysis if it’s a manual process.

Source code analysis tools can be too noisy/time-consuming at which point people will ignore them or want to rip them out.

I like Aaron Maenpaa’s way of describing potential drawbacks:

Two common pathologies occur when using static analysis tools:

  1. The tools produce spurious warnings/errors that the developers cannot silence. Eventually, most of the warnings are spurious and the developers stop paying attention to the output. This is why many teams require that code compile cleanly. If developers feel comfortable ignoring compiler warnings, the compile phase will eventually be filled with warnings nobody ever pays attention to, even though they may be bugs.
  2. The tools take too long to run and developers never bother to run them.

Source: http://stackoverflow.com/a/49731/132931

Helpful resources:

← Go back to the intro