All too often, application development professionals believe that application security is not their responsibility. To make matters worse, this belief is shared by their managers and CIOs, and reinforced by organizational structures and job descriptions. When asked about application security, developers might say:
When asked who should take care of application security, they point to the security team.
Asking the security team the same question, you will often hear:
When asked who should be responsible for application security, they point to the development team.
Unfortunately, cyberattackers often know security better than application developers, and know application development better than security specialists. Both Dev and Sec feel that they are successful with their objectives, but when it comes to application security, this success is false. The gaps that exist between security and development teams have traditionally resulted in a situation when neither Dev nor Sec addressed application security completely, leaving security gaps exploited by cyberattackers.
We believe that, with the emergence and advancement of DevOps and CI/CD, application security can be integrated into these processes, and a great deal of AppSec responsibility can be handed over to development teams without slowing down software development or delivery.
Development teams can start by learning and adopting secure coding practices through educational organizations or application security testing vendors. Best practices for secure coding can also be found on websites of organizations such as OWASP.
Developers should adopt manual code reviews and, more importantly, automated code reviews conducted by technologies such as static application security testing (SAST) that analyze application code in pre-production states for security vulnerabilities, point to their origin, and offer remediation advice. Developers should also adopt software composition analysis (SCA) technologies that analyze applications for the presence of third-party (mostly open source) components with known security vulnerabilities. At test phases near production, applications should be tested with dynamic testing technologies (DAST) that discover vulnerabilities in running tested applications.
Those technologies – SAST, SCA, and DAST – have often been too complex for developers to operate, leaving dedicated experts to operate them. Over time, a few changes have occurred, making it easier for developers to take advantage of them:
DevOps has the opportunity to become DevSecOps. It can be rapid, incremental and continuous. And it can be driven by development and operation specialists. It should be their responsibility to ensure that application security processes are invoked at proper phases of the software lifecycle, and that detected vulnerabilities are fixed and protected. If we do that, we close the gaps between great software and great security, and we’re all better off.