Last updated at Tue, 28 Nov 2023 18:36:40 GMT

Integrating Application Security with Rapid Delivery

Any development shop worth its salt has been honing their chops on DevOps tools and technologies lately, either sharpening an already practiced skill set or brushing up on new tips, tricks, and best practices. In this blog, we'll examine how the rise of DevOps and DevSecOps have helped to speed application development while simultaneously enabling teams to embed application security earlier into the software development lifecycle in automatic ways that don't delay development timeframes or require major time investments from developers and QA teams.

What is DevOps?

DevOps is a set of methodologies (people, process, and tools) that enable teams to ship better code – faster.  DevOps enables cross-team collaboration that is designed to support the automation of software delivery and decrease the cost of deployment. The DevOps movement has established a culture of collaboration and an agile relationship that unites the Development, Quality Engineering, and Operations teams with a set of processes that fosters high-levels of communication and collaboration.

Collaboration between these three groups is critical because of the inherent conflict of development organizations being pressured to ship new features faster while operations groups are encouraged to slow things down to be sure that performance and security are up to snuff.

DevSecOps and Application Security


Getting new code out to production faster is a great goal that often drives new business, however in today's world, that goal needs to be balanced with addressing security.

DevSecOps is really an extension of the DevOps concept. According to DevSecOps.org, “It builds on the mindset that "everyone is responsible for security" with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required.

Web application attacks continue to be the most common breach pattern confirming what we have known for some time- that web applications are a preferred vector for malicious actors and they are difficult to protect and secure. According the 2016 Verizon Data Breach Report, 40% of the breaches analyzed for the 2016 DBIR were web app attacks. Today's web and mobile applications pose risk to organizational security that must be addressed. There are several well-known classes of vulnerabilities that can be present in applications; SQL Injection, Cross-Site Scripting, Cross Site Request Forgery, and Remote Code Execution are some of the most common.

Why are Applications a Primary Target?

Applications have become a primary target for attackers for the following reasons:

1. They are open for business and easily accessible: Companies rely on firewalls and network segmentation to protect critical assets.  Applications are exposed to the internet in order to be used by customers. Therefore, they are easy to reach when compared to other critical infrastructure and malicious attackers are often masked as legitimate desired traffic.

2. They hold the keys to the data kingdom: Web Applications frequently communicate with databases, file shares, and other critical information.  Because they are close, if they are compromised it is easier to reach this data which can often times be some of the most valuable.  Credit Card, PII, SSN, and proprietary information can be just a few steps away from the application.

3. Penetrating applications is relatively easy. There are tools available to attackers that allow them to point-and-shoot at a web application to discover exploitable vulnerabilities.

Embed Application Security Early in the SDLC - A Strategic Approach


So, we know that securing applications is critical. We also know that most application vulnerabilities are found in the source code. So, it stands to reason that application vulnerabilities are really just application defects and should be treated as such.

Dynamic Application Security Testing (DAST) is one primary methods for scanning web applications in their running state to find vulnerabilities which are usually security defects that require remediation in the source code. These DAST scans help developers identify real exploitable risks and improve security.

Typically, speed and punctiliousness don't go and in hand, so why would you go about mixing two things that might be thought of as having a natural polarity? There are several reasons that implementing a web application scan early in the SDLC as part of DevOps can be beneficial and there are ways to do it so that it doesn't take additional time for developers or for testers, it can be baked in as part of your SDLC and part of your Continuous Integration process.

When dynamic application security testing first became popular, security experts often conducted the tests at the end of the software development lifecycle. That only served to frustrate developers, increase costs and delay timelines. We have known for some time now that the best solution is to drive application security testing early into the lifecycle along with secure coding training.

Microsoft was one of the early pioneers of this with their introduction of the Secure Development Lifecycle (SDL) which was one of the first well-known programs that explicitly stated that security must be baked into the software development lifecycle early and at every stage of development not bolted on at the end.

The benefits of embedding application security earlier into the SDLC are well understood. If you treat security vulnerabilities like any other software defect, you save money and time by finding them earlier when developers and testers are working on the release.

  • Reduced Risk Exposure -The faster you find and fix vulnerabilities in your web applications mean less exposure to risk. If you can find a vulnerability before it hits production you've prevented a potential disaster, and the faster you remove vulnerabilities from production, the exposure you are faced with.

  • Reduced Remediation Effort - If a vulnerability is found earlier in the SDLC then it's going to be easier and less expensive to fix for several reasons. The code is fresh, the developer is familiar with it and can jump in and fix it without have to dig up old skeletons in the code. There is less context switching (context switching is bad) when we find security defects during the development process. Additionally, if a vulnerability is found early then it is much more likely that there won't be other code relying on it so it can be changed more safely.  Finally, new code will be less likely burdened with tech debt and therefore be easier to fix.

  • Reduced schedule delays - Security experts are well aware that development teams don't want to be slowed down. By embedding application security earlier in the SDLC, we can avoid they time delays that come with testing during later stages.

These factors should help explain why incorporating application security into a DevOps mentality makes sense.  So how can a security-focused IT staff member help the developers get excited about this?

Adopting a DevSecOps Mindset for Application Security - 8 Best Practices

Build a Partnership

Partnership and collaboration is what DevOps is all about. Sit down with your development team and explain that you aren't trying to slow them down at all. You simply want to help them secure the awesome stuff they are building. Help them learn by explaining the risk.  The ubiquitous “ALERT(XSS)” doesn't do a good enough job of pointing out the significance of a cross-site scripting vulnerability. Talk your developers through the real-world impact and risks.  

Conduct Secure Code Training

Schedule some “Lunch-n-Learn”s or similar session to explain how these vulnerabilities can emerge in code.  Discuss parameterization and data sanitization so developers are familiar with these topics.  The more aware of secure coding practices the developers are, the less likely they are to introduce vulnerabilities into the application's code-base.

Know the Applications

It helps when the security expert understands the code base. Try to work with your developers to learn the code base so you can help highlight serious vulnerabilities and can clearly capture risk levels.

Security Test Early, Fail Fast.

Failure isn't typically a good word, but failing fast and early is an agile development mindset that is applicable to application security. If you test early and often you can find and fix vulnerabilities faster and easier. The earlier new code is tested for security vulnerabilities the easier it is to fix.

Security Test Frequently

Test your code when new changes are introduced so that critical risks don't make it past staging.  Fixing issues is easier when they are fresh. Scan new code in staging before it hits production to reduce risk and speed remediation of issues.

Integrate Security with Existing Tools

Find opportunities a solution that to embed dynamic security testing early into your software development lifecycle by integrating with your existing tools. Seamlessly integrating security into the development lifecycle will make it easier to adopt. Here are some of the most effective ways of integration security testing into the SDLC:

  • Continuous Integration - Many organizations achieve early SDLC security testing by integrating their DAST solutions into their Continuous Integration solutions (Hudson, Jenkins, etc) to ensure security testing is conducting easily and automatically before the application goes into production. This requires a application security scanner that works well in “point and shoot” mode and includes an open API's for running scans. Ask your vendor how their scanner would fit into your CI environment.

  • Issue Tracking - Another effective strategy for building application security early into the SDLC is ensuring your application security solution automatically sends security defects to the issue tracking solution, like Jira, that is used by your development and QA teams.

  • Test Automation - Many QA teams are having success by leveraging their pre-built automated functional tests to help drive security testing to make security tests even more effective. This can be done through browser automation solutions like Selenium.

Rapid7's AppSpider is built with this in mind and includes a broad range of integrations to suit your team's needs.

AppSpider is a DAST solution designed to help application security folks test applications both as part of DevOps and as part of a scheduled scanning program. Thanks for reading and have a great day.