Six Best Practices for Security Testing in

the SDLC
Author: Pavankumar Bolisetty

Six Best Practices for Security Testing

in the SDLC
Even if an application has been built following security and defensive coding best practices, it will still
require significant testing before its ready for release.
Whether this is routine testing for common vulnerabilities or security-focused penetration testing to
pick up on the types of problems that often slip through the cracks, following security best practices will
help your dev team find and fix problems before the deployment phase of the SDLC.
Today Im looking at six best practices for security testing your application.

1) Look for What Isnt There

With security testing you are more concerned with finding functionality that isnt supposed to be there,
rather than with specification-based testing which makes sure your code does what its supposed to do.
Instead of testing that your application delivers the anticipated outcomes, you will be looking for
unexpected side effects or behaviors that arent specified in the design. This will help you identify hidden
vulnerabilities that could be exploited by anyone trying to gain access to your applications data.

2) Test Outside of Public Interfaces

Security testing can all too often be a matter of forcing as many inputs through an applications API as
possible. However, the inputs that arrive to an application through its API and other public interfaces are
far outnumbered by those that arrive from the network and file system.
Copyright E Com Security Solutions 2016

Page 2 of 3

Six Best Practices for Security Testing

in the SDLC
Therefore, its much more important to test inputs that arent coming from public interfaces as this is the
first place that attackers will look for a way in to access your sensitive data.

3) Static Analysis
Static analysis inspects code at rest without executing the program. It allows developers to perform a
thorough inspection of every aspect of the softwares source code, in order to identify any flaws or back
doors that will make your application vulnerable to attack.
Static analysis tools, which read through your software code, can be programmed to look for clues that
point to vulnerabilities that your developers may not have identified during code reviews.

4) Dynamic Analysis
Dynamic analysis is the natural follow-on from static analysis. Dynamic testing is performed in a runtime
environment, with security analysis carried out while the application is in operation. Dynamic analysis
can reveal vulnerabilities and flaws that may be too subtle or complicated for static analysis to pick up
on. Dynamic testing tools can uncover hidden problems like memory manipulation or file access that
dont appear in plain view in the applications API.

5) Test the Deployment Environment

A single misconfiguration or mistake in the setup process can render an otherwise secure application
vulnerable. Therefore, it is vital to check for configuration errors before deployment.
If youre deploying an application to a server, you will need to check it for security. You will want to scan
the server for open ports, review configuration files, and ensure that attackers cant gain access to
sensitive files or directories via the server.

6) Test Incident Response Procedures

Dont wait until a security breach takes place to find out if your incident response procedures are up to
the task. By running breach simulation exercises with any high-priority vulnerabilities identified during
security testing, you can test your organizations reaction to fixing the problem and developing and
implementing the security patch. This means that if a serious breach occurs after deployment, your
organization will be well practiced in incident response and remediation.

Copyright E Com Security Solutions 2016

Page 3 of 3