By Mark Rogan, DAST application security supervisor, WhiteHat Security
Us and them…
Cybersecurity and development teams have traditionally been at odds with each other during each step of the software lifecycle. To the development team, the security team has often been seen as the gatekeeper that put the brakes on the rapid pace of code development needed to keep up with competitors and customer demand. To the security team, developers have been viewed as mavericks with a ‘wild west’ approach to security checks and balances—and who don’t give enough thought to application and software security. As with most arguments, however, the truth is somewhere in the middle.
The misunderstanding from both sides stems from the fact that there is more pressure than ever before on both teams: There is a greater number cybersecurity threats—many of which have grown in sophistication and insidiousness. This means security must be paramount and entrenched in app development—no matter how fast or frequent. But there is greater pressure on developers too. More organizations are embracing agile, fast waterfall app development. For some development teams that means it’s common to release several times per week, or even several times per day. In extreme situations—with teams implementing continuous delivery—it’s not uncommon for software builds to be released every few minutes. In the rush, it’s possible for security to take a backseat, despite the better intentions of the development team.
The birth of DevSecOps: And why it matters
With the old ways of working—where security was a check point to production—it seemed both teams were at a bit of an impasse. The same business and the same execs appeared to be demanding two conflicting things. Fast app development to drive the business and measured security controls to protect it. No wonder an “us and them” situation manifested itself.
Today, however, the most successful organizations have flipped that way of working on its head—pushing security to the beginning of the development process and using it as a check at each subsequent stage. For the uninitiated, this framework of working is often called DevSecOps. By placing security literally in the center of development and operations, businesses have a better chance of building and releasing safer software.
Many businesses go further by encouraging the security team to educate and empower the development team—either by providing AppSec tools or offering direct on-the-job training (or a mixture of both). If done correctly, over time, the development team can become more self-sufficient and be in a position to correct potential security threats in their code themselves at a much earlier stage. It also encourages skill growth within the organization and, in the long-term, might even lead to coders making the once unthinkable switch to a security role within the organization.
When you think about it, this approach makes a lot of sense. Developers by nature are focused on the fast release of new products, features and functionality, but that doesn’t mean that they actively want to push out code that isn’t secure. In some instances, however, developers just don’t have all the tools and skills necessary to write secure code. This isn’t necessarily their fault—particularly in the early years of their career—as software security and secure code development isn’t always a part of standard programming course.
Smaller organizations and the security champion
Smaller organizations that haven’t invested in a dedicated security team might be tempted to think they don’t have a potential conflict between security and development. But that would be foolish. As we’ve said, the pressure to develop apps at speed and the sheer volume of cybersecurity threats mean that, at some point, there will be a conflict of interest—even if it is not played out between actual teams or departments. There still needs to be security checks and balances at each stage of the software development lifecycle, even if there isn’t an actual security team to offer advice, understanding and action.
For this reason, smaller organizations have found they are very well served by employing a dedicated “security champion.” Security champions can ensure that these checks and balances are in place—and also ensure security-related best practice and education are disseminated across the business.
Practical education and empowerment unwrapped
Regardless of whether security knowledge and best practice is driven by a security team or a security champion, one of the most practical things that can be done to help empower developers is to introduce AppSec tools to the developer workspace. Some AppSec tools can eliminate security issues before software is committed to version control or the release pipeline, while others can flag security vulnerabilities in live applications.
This gives more security-related responsibility to the development team and allows them to check their own work. Psychologically, that’s got to be better than being reprimanded by another department at the eleventh hour when the pressure is on. AppSec tools can often offer a clear explanation as to why lines of code may have been compromised and help prevent the development team from making similar errors in the future. This should make for a more positive and respectful relationship between the security and development teams.
Security teams or a security champion can generate reports from AppSec tools and get a strategic overview of the most commonly flagged security threats. This enables the security team to offer specific on-the-job training or recommend suitable external courses to help the development team plug any potential knowledge gaps and avoid similar issues in the future—when the deadline has been met and pressure has passed.
Analyzing AppSec tool metrics such as vulnerability likelihood by class and remediation by risk could also give security teams or champions further insight into the most common and serious security threats and give them the option to develop or purchase a library of pre-approved application development templates that the development team could use without worry.
AppSec tools also allow developers the ability scan their code for security vulnerabilities as a part of their iterative, fast-paced, agile SDLC processes.
Conclusion
Modern cybersecurity is about managing risk through collaboration, enablement, and organization-wide learning—and removing the friction that historically existed between security and development silos. This is really important if large enterprises are to keep pace with more nimble start-ups that push frontiers with scalable and secure software development. Only by security and development teams working together can businesses keep pace with their rapidly changing markets and maintain their leadership positions.
