How Often Should You Assess Apps for Security?

Those new to AppSec might wonder – how often do I have to test my apps for security? One school of thought is: do a one-time scan of all or most apps in production, fix the most egregious defects and either consider security testing “done” – or maybe schedule another scan in several months, even for the next year.

The problem with this model is that it doesn’t work with the way software is currently developed, or used. Software now powers the world; we rely on it to make business decisions and interact with customers and partners. As its role has become more prominent, the way it is developed is changing, and the ways to secure it need to change as well.

Today, software is ubiquitous, produced at a lightning pace and introduced into your organization by various departments and individuals. And its development has become a continuous, integrated process that reaches beyond your internal development team. These characteristics allow your organization to grow and innovate like never before, but also require you to think about security differently.

Thinking about scanning only completed code, or only code in QA, won’t work with today’s security or development landscapes.

Beyond QA

Another application security “school of thought” is: save it for QA. Developers hand off their completed code to the security team, who test it with static, dynamic and manual pen tests – then a whole round of back and forth based on the findings ensues.

Those QA tests are still a critical part of software development, but thanks to a new emphasis on security, and new development methods like Agile and DevOps, security as a roadblock to production is no longer feasible. Security assessments need to play a role throughout the application’s lifecycle, from dev to QA to production – leading to more secure code with less roadblocks.

Shift left

Shifting security “left” in the development process not only saves you time, but also money. In fact, the National Institute of Standards and Technology (NIST) has found that it is 30 times more expensive to fix a vulnerability during post-production than during earlier stages.

Make embedding security into development processes easier by using automated scanning solutions that call AppSec APIs from the development tools already being used by programming teams. Also consider solutions that offer developers “sandbox” functionality – which enables development teams to test and fix code between releases without triggering a failed policy compliance report to the security team.

Another consideration is training on secure coding. eLearning that is integrated into an application security solution will give developers quick guidance on fixing security-related code defects, preventing them from getting hung up due to lack of knowledge.

In this way, your development team is assessing and fixing as they go, creating higher quality code faster.

Shift right

Security assessments don’t end when coding does. Don’t neglect the security of apps in production. And don’t think you can scan production apps once, or once a year, and be secure. Vulnerabilities will inevitably sneak into production apps. Why? Because time to market often trumps security, or new vulnerabilities are introduced as applications are updated or enterprises are using third-party apps that cannot be mitigated.

Emerging runtime protection solutions arm apps in production with the ability to defend themselves against attacks. This technology identifies and blocks application security threats in real-time. By adding detection and protection features to the application runtime environment, RASP enables applications to “self-protect” by reconfiguring automatically, without human intervention, in response to certain conditions. In this way, production apps are continuously “assessed” for security.

In addition, our most recent State of Software Security report, which analyzes the data we have accumulated assessing code for the past 18 months, found that three of the top four vulnerability categories found by dynamic testing involve the misconfiguration of protection mechanisms. In essence, developers are introducing vulnerabilities by poorly configuring elements that are actually meant to keep application data safe. These results point to the need for dynamic scanning of apps in production as well.

Security shift

In the end, organizations today need to change their mindsets about assessing the security of software. Security assessments are now an incremental, continuous process – that starts early in the development phase, continues through production, and keeps going as the app remains in production and is updated over time.

How often are you assessing apps? Are you testing software outside of QA? Are you in line with what your peers are doing? Check out the results of our recent survey to find out: Trends and Tactics: How IT Professionals Are Approaching AppSec Today.