The Gap Between Development and Security Specialists Should Be Closed

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:

• They are responsible only for application functionality and quality.
• They are not security specialists.
• They do not have the time or skills to address application security.
• Their work is not driven by security concerns.
• Security is not their priority.
• Their priority is to deliver required application functionality by a deadline and under budget.

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:

• Its team members are busy with installing, operating and tuning network firewalls, antivirus software, web gateways, data loss prevention systems, etc.
• They are not programmers and don’t know programming languages and application development methodologies. Therefore, they cannot be held responsible for application security.
• At best, they whitelist applications for end-point protection systems.

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.

Bridging the AppSec Gap

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:

• These technologies are now available as cloud services. Developers do not need to install or operate them. They only need to request their execution from cloud services, which will test applications on developers’ behalf, so that developers will only need to remediate vulnerabilities detected by the services.
• These technologies can be invoked programmatically via APIs at the defined events, such as upon completion of compilation or build process.
• These technologies have been evolving to support individual developers, enabling their invocation out of IDEs and returning test results back to IDEs.

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.