Application security testing is no easy feat. And yet, it’s usually the first topic that most articles about application security address. The reasons are simple: As the pace of application development techniques (and their inevitable vulnerabilities) evolve, AppSec personnel have found themselves caught between the desire to keep pace with their management of security testing requirements and their ability to allow the developer teams to operate in the modern, fast-paced ecosystem of DevOps and artificial intelligence.
To better understand the best practices for conducting AppSec testing in the era of DevOps and AI, it is important to first appreciate the technologies available to us, that allow us to do so.
At the heart of the modern application security testing, there are five main technologies to be aware of:
- Static application security testing (SAST)
- Dynamic application security testing (DAST)
- Software composition analysis (SCA), third-party code
- Penetration testing
These five technologies account for the bulk of most of the activities around application security testing. However, many aspects of application security testing are rapidly changing, including efforts to incorporate automation and artificial intelligence into the equation.
By including automation or AI, for example, code testing is allowed to be released in rapid fire sequence, with production use approvals baked inline through automated logic and decision-making. This idea of continuous integration/continuous delivery (CI/CD) can lead to a widening of fractures between the security and development teams. Therefore, DevOps users today need the ability to program their code and test it through automated code scanning techniques before pushing the code into secure staging environments.
To successfully conduct application security testing in today’s era of advancing developer operations through automation and artificial intelligence, there are three critical best practices to keep in mind.
- The Earlier, the Better: Introduce appSec testing into the software development life cycle early on for maximum results: Regardless of the type of testing being conducted, waiting until the very end of the development process will only create more work. Users will either end up with more bugs than they could feasibly fix or find themselves a part of an overworked AppSec team as they attempt to document and deliver on discovered vulnerabilities and code flaws. Statistically speaking, code changes that happen later in the development life cycle are also more costly to the business.
- Conduct testing of business-critical applications as often as possible: When deciding which assets are next in line for application security testing, one should consider the applications and systems that are of critical business value to the organization’s revenue stream. Think of these systems in particular as the “crown jewels” for the majority of attacker motives, since they define the amount of money a given organization will procure for that day and, if attacked, could disrupt the business in myriad other ways.
- Test for third-party code security and interoperability flaws as you would your own software: The growing complexity of modern applications means there is a need to leverage open source or third-party components. As this is the case, these components must also receive the same level of scrutiny as the applications in one’s own enterprise. All third-party code referenced in the software delivery process must also be checked by performing software composition analysis for security and interoperability flaws.
While the pace and techniques for AppSec testing will undoubtedly continue to advance, and while there are some AppSec testing techniques that may never become obsolete, it is imperative to ensure that one’s system for maintaining application security testing always adheres to the best practices to preserve a secure software environment for the future.