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.

More from Application Security

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Audio-jacking: Using generative AI to distort live audio transactions

7 min read - The rise of generative AI, including text-to-image, text-to-speech and large language models (LLMs), has significantly changed our work and personal lives. While these advancements offer many benefits, they have also presented new challenges and risks. Specifically, there has been an increase in threat actors who attempt to exploit large language models to create phishing emails and use generative AI, like fake voices, to scam people. We recently published research showcasing how adversaries could hypnotize LLMs to serve nefarious purposes simply…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today