Every day, new application vulnerabilities put companies at risk. Too often urgent desire for new features wins out over presumption that security will bog things down. While everyone on a DevOps team should have a security mindset, that is often cast aside for the sake of speed and the desired cadence of launching new products. The “DevSecOps” hashtag is simply to remind us of all to test for security throughout the process rather than at the end (or, not at all).

I hear from most application development teams that they don’t believe security is their responsibility and they really don’t want to add to their queue. However, there are tangible benefits for dev teams that recognize that they are responsible for security — and the old model of security vulnerabilities being found after apps go to production is just no longer acceptable.

Even detecting security vulnerabilities just before production creates some lengthy rework cycles. Or worse, if the weak code slips though to production and only gets discovered in annual penetration tests creating rework and emergency.

Once the quality assurance team has assessed quality, performance, and integration testing, finding a security issue only causes friction with the developers. All the QA (Quality Assurance), Performance testing, and release management work has been a complete waste of time and it is back to the start for that feature.

Bake in Security from the Start

If we bake in security from the start, by using a tool like Micro Focus Fortify, we can avoid problems that typically occur later in the development process. This suite of tools brings security visibility and critiquing to all stages of the software build process. As a developer is typing code directly or cutting and pasting open-source code, Fortify uses its static code analyzer to quickly scan and evaluate the code as it is entered to look for potential vulnerabilities and makes security recommendations. It’s like, “Grammarly,” but for programmers.

Fortify has a plug in for the Integrated Development Environments (IDE) where developers work; it doesn’t matter if that’s Visual Studio, Eclipse, or IntelliJ IDEA. When the developer is finished writing code, it’s checked into the code repository. Then, nightly, a deeper scan is run that looks deeper for security vulnerabilities as well as any potential licensing infringement and automatically logs a ‘defect’ in the popular issue tracking tools like Bugzilla, Jira, or ALM (Application Lifecycle Management) Octane.

For example, if a developer found an open-source routine from an internet library, such as a pop-up window to select a date on a calendar, and it could contain malicious code. More subtly, that calendar code may not be completely free, and require creative commons attribution. Or sometimes code may include additional unnecessary libraries from various sources. Fortify is also great to detect and log those types of issues and vulnerabilities.

Real World Testing Before Real World Deployment

Then there’s the testing process, where we build a testing environment for the developers. Now it’s compiled code, and we test it again because we have only looked at the programming language and not yet at how the app behaves. Fortify includes DAST (dynamic application scanning testing), so we scan the production-ready program to understand how it will work in the real world and look for new vulnerabilities. This captures not just potential code vulnerabilities, but also the method that the code is configured and deployed on servers and hardware. What makes Fortify unique is that it provides static code scanning as well as dynamic application scanning; one cross-references the other and cancels false positives.

Fortify is flexible: It can be deployed at the customer site on-premises without any access to the internet, in a very secure, disconnected (“air gapped”) environment, or Fortify can be deployed as a service without anything to install. Many customers prefer the as-a -service model because it’s one less thing to maintain and one more tool in the security toolkit.

Every week, major software breaches are in the news. Cyber hacks are pervasive, and reputations and business are at stake. Equifax leaked 145 million Americans most sensitive date in 2017 with the credit reporting bureau didn’t correctly prioritize security. Then CEO Richard Smith named the employee responsible and pointed the finger directly at him: claiming that the vulnerability was posted publicly, and employee didn’t act fix it (something Fortify would have caught). I’d never seen lack of accountably by leadership before — and I hope I never see it again. But that should be a warning: Developers, your name and reputation are on the line.

Ensuring that applications are secure from the ground up makes developers’ lives better, testers’ lives better and the operations teams’ lives better. Everybody benefits, including your customers.