Last December, Neil Jones published a collaborative blog post discussing automated security services in the cloud and how they help development teams. In this post, I would like to further discuss the use case for automated services, but with a concentration on how to seamlessly integrate them into the build process to achieve the ever-desired secure development life cycle (SDLC).

Making the Case for Application Security Testing in Your SDLC

First, I’d like to provide my perspective on the importance of the SDLC. It’s a known fact that in the development process, the earlier you find a defect, the less costly it is to resolve it. A security vulnerability is a defect, and as such, you want to catch it as soon as you can.

Although considering security early on in the development stage is good, running security tests during the development life cycle is better. Ultimately, integrating testing into your build system is the best approach. So, why doesn’t every development team follow these guidelines? The reasons can vary, but it is primarily a matter of cost. In order to claim SDLC status, the team needs to employ security experts to configure and run the scans, verify the results, invest in security scanning tools to run tests and then integrate them into the build process. These capabilities aren’t always intuitive to most organizations.

Automating Cloud Security Requires Three Key Capabilities

You can probably guess where I’m heading. I propose that the use of automated cloud security services is the best solution here. With limited effort and relatively low cost, you can accomplish this work and improve your overall security posture. However, this proposal assumes your service provider takes into consideration the following important capabilities:

1. Application Programming Interface Support: First and foremost, your service provider needs to be able to conveniently launch a security scan on demand from a code/script/build environment at the required time. For static application security testing or mobile application security, this occurs when compilation ends. For dynamic application security testing, it occurs after the site is deployed. Usually, the security analysis step would begin when the automated quality assessment step successfully ends.
2. Fully Automated Solution: Naturally, the service needs to run without human intervention. Because a security scan is just another part of the build process, the entire operation will not be complete until the scan results are delivered. If the service is not fully automated, a security team member (perhaps on the service provider side) needs to configure, run or validate the results. This makes the service unusable for the build process. For example, an application programming interface (API) must be offered as part of a service, since no matter how simple and functional an application security service is, organizations will need to integrate it into their build processes. Otherwise, someone would need to manually invoke the API; thus, it couldn’t be used as part of the SDLC. Of course, if a service provider can ensure a manual process will never delay your results and can prove it, you should consider it.
3. Availability: For the same reasons as above, if the service isn’t available to users on a 24/7/365 basis and can’t deliver its results within a reasonable amount of time, it cannot be deployed as part of the build process.

My intent is not to minimize the importance of services being accurate, simple and fast. Those are basic requirements of any cloud service. However, to be able to claim that a solution supports the SDLC, your cloud security service should offer these three capabilities, just like any good on-premise security scanning tool would offer.

Seeing the Benefits of Automated Application Security Testing

Because automated cloud security is a new field, it is still evolving. It may take a few years before these services really offer a point-and-shoot solution that is fully hands-free. Some monitoring is still required, and the service provider might need to configure initial scans. However, if you look at the big picture, having a few initial manual steps is a small price to pay. For instance, having the option to employ these services for daily or weekly build processes in your ongoing development life cycle can make a dramatic difference.

Is IBM meeting these criteria with its IBM Application Security on Cloud service? Naturally, I believe we are, but I urge you to register for a complimentary trial and test-drive it yourself.