Despite the many hacks and breaches consistently making headlines, businesses can't afford to slow down their development processes because they don't want to lose out to the competition. This places them in an awkward position: deciding between speed and an extra step for the sake of security. But the worry is misplaced; companies don’t need to trade speed for security or security for speed.
A recent study conducted by Veracode and Enterprise Strategy Group (ESG) concludes that, despite the widely held belief that security is at odds with development, both security practitioners and developers want to build secure software while focusing on innovation. More than half of respondents (58%) reported that their organization is taking a collaborative approach to application security already.
Evidently, developers and security teams alike are aware that security tests have often been done too late in the process to be effective. However, when security testing is done throughout the software development process, developers can find issues faster, have more success, and keep up, or even improve, production levels. All it takes is removing the wait for security.
The DevSecOps takeover
Software has become the cornerstone of innovation and economic growth, even expanding to industries traditionally less reliant on technology. It’s involved in everything from sports to farming. As such, it is a priority for IT professionals that the faux friction between security and development be removed. It’s the only way security and DevOps, or DevSecOps, can come into their own and evolve into the DevSecOps process required for the application economy to thrive.
DevOps is taking over as the primary form of development for most organizations because it has been proven over time to dramatically improve performance while delivering on software needs at rates previously not possible. This is an opportunity for security to fit in—45% of respondents to the Veracode/ESG survey whose organizations have adopted formal DevOps principles indicate that DevOps makes their job easier. Only 8% think introducing security into the current schema will slow down the DevOps process.
These numbers stand in stark contrast to the pervasive belief that security is at odds with development. In fact, among respondents reporting the use of application security tools such as static monitoring in their DevOps processes, 43% report that their organization does it because application security in the development process is more efficient than reactively patching problems as they arise.
Changing technology requirements
This change in mentality couldn’t have come at a better time. The research clearly points to the need for application security to become an integral aspect of the DevOps process. But now that we’ve overcome the mental barrier, we need to work on the technology so it can seamlessly work together.
Tools can seem complex, especially when first introduced to users. This and the inability to integrate new solutions seamlessly into the DevOps workflow are major obstacles that need to be dealt with before DevSecOps becomes a reality. Consider that the ability to integrate static software testing and software lifecycle tools is the top consideration (42%) when evaluating security-testing products. It’s the same for dynamic software testing and software lifecycle solutions (34%).
Fortunately, it’s not an insurmountable obstacle, and a lot can be done today to better integrate security into DevOps to help it become DevSecOps. Here are fives steps:
1. Automate security invocation
This requires a comprehensive API to initiate, control, and return results from software testing. It should include first-class support for the common tools of development teams such as IDEs, CI servers, and bug-tracking systems.
2. Integrate to “fail quickly”
Inspecting quality into the product as early as possible is part of the DevOps philosophy. It should start when the developer begins to code. Integrating security into the IDE to scan code as it’s being written not only alerts developers to problems as they’re introduced, but also has an educational effect that can train the developer to code securely from the start. As I like to say, I want the code to come out of developers’ fingers secure.
Give developers the tools necessary to take the test before the test. In other words, after they have scanned the modified code, give them the ability to quickly assess the entire application prior to check-in so that they can prevent insecure code from being checked in.
Finally, security testing should be part of the CI/CD pipeline. This is the “trust but verify” stage, more commonly referred to as an assurance scan. This should always be green and lets you know that developers are following a strong process in the educational and preventative stages prior to check-in.
3. Ensure no false alarms in the process
As the industry has learned, a technology that reports too many false positives will be ignored and won’t be adopted. It wastes too much valuable time. This is doubly true in CI/CD, where a failed security test may stop a critical business function from being delivered to production—or a critical patch from being released. That may be tolerable if the security issue is real, but it is intolerable if the finding is a false positive.
4. Build security champions
Most security teams are too small to actively engage all of the development teams. Security champions are a great way to extend your reach. Training one or two developers from every application team makes it possible for security to always be in the room. The training is beneficial to both the company and the employee. Picking the right champion is key, though. Look for the influencers.
5. Keep operational visibility
Security should not stop after deployment. As with other aspects of DevOps, a well-engineered solution must have a closed feedback loop from production, in case of security issues. Production dynamic application security testing (DAST) is a great way to identify configuration drift from your pre-production environments, and runtime application self-protection (RASP) can be the air bag that prevents a breach from a vulnerability that may have eluded detection. Finally, you must understand the bill of materials as it exists in your production environments, because of the inevitable zero-day vulnerabilities that exist in your open-source software. This will arm your incident-response team with valuable information to more quickly react to new threats.
DevSecOps: Security in the middle
Ultimately, application development methods such as DevOps have fostered more communication and collaboration across departments, including development, operations, and security. It’s now becoming DevSecOps.
The goal: to deliver the best product with the least amount of issues, both in functionality and security. The next step is the seamless integration of that third component—security—early into the process to deliver the best result. Remember, secure code is quality code. Are you achieving it?
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
