Far too many software development teams, executives, and users think security is just tooling, cryptography, coding, apps, and various hardware devices. In reality, though, it’s just as much a state of mind. In short, teams have to think seriously about security culture to build truly secure software.
Nowhere is this more critical than with application security. Yes, developers must internalize risks, threats, and security rules. But if they don’t understand and agree with the rationale behind those rules, they are likely to abide by the letter of the law and not the spirit.
1. Security Has To Be Everyone’s Responsibility
Developers are perhaps the most critical players to maintain security, simply because of the widespread damage a security hole inside a widely-used app can unleash. However, security needs to be incorporated into every single stage of the software development lifecycle, and by everyone involved in it.
Organizations need to break the silos between sec dev and ops. In short, get everyone to understand that all players involved are trying to help the company flourish, each in their own ways. This will dilute the perception of security as “The department that says ‘no.’”
2. Listen to the people involved in the SDLC to eliminate frictions
At the same time that the organization demands everyone to participate in the security of the software, it must be receptive to the input that this large and diverse group has to provide about the SDLC security process. Specifically, if this feedback presents an opportunity for improvement.
The goal is to help them be more secure in as effortless as viable. Where practical, leverage automation to find and negate problems before they undermine the users’ goals. Do so in a way that minimizes both false positives and false negatives, as both of those undermine trust in the tooling and in the value of security. Favor tooling that report results in real-time, interactively, vs lengthy scan times. Users and executives are not known for their limitless patience. Long scan times strike many as productivity killers. Also, make sure that systems do not deliver static that are quickly out-of-date. That, too, undermines security’s credibility and authority.
3. Incorporate training aspects into your tooling
First, security tooling must provide remediation advice as often and as specifically as possible. When viable, the systems should deliver full visibility, not only for actual problems but for potential problems.
And second, invest in quality developer education focused on the practical aspects of building secure software. This does not have to be expensive or excessively time consuming, as there are plenty of resources available for free. We really like the materials that OWASP, the main non-profit organization pushing forward the application security domain, publishes regularly.
4. Communicate that there is no quality without security
How can software be considered high-quality if it delivers unauthorized access, leaks sensitive data or conflicts with other apps in the enterprise? High quality equals high security.
It is critical to not confuse great functionality with great software. Great software will almost always deliver great functionality and ease-of-use, but if it brings with it security breaches, downtime, lawsuits and forensic investigations, how great is it in reality?
5. Gain senior-level support and involvement
Executives at all levels need to understand the security goals of the organization and be familiar with the ROI of the secure software process. Those are concepts that CFOs and CEOs—and board members—are comfortable. Speaking their language is always the best way to communicate, regardless if the software is for internal and partner use or if the final product is to be sold externally.
Secure code means faster time to market, happier sales executives, happier end-user customers, and more. How about better recruiting and longer retention? A strong security culture frequently delivers both of those, as both security and developers experience less friction.
Security automation allows developers and operations teams to spend a higher percentage of their time building the more interesting parts of the application. That equals higher morale, which boosts retention.
The Hdiv Unified Security Platform as a solution
At Hdiv, we take seriously all the elements required to build secure software. Hdiv Detection (IAST) fosters collaboration across all teams and provides accurate information that includes full details and remediation advice. Hdiv Protection (RASP) automates the protection of serious risks so that your developers can be productive while releasing secure software.
If you liked this post, make sure you check out our advice on successful adoption of DevSecOps.