In a world where enabling a fast pace of change is critical to keeping up with customer requirements, and providing our customers with more and more ways to engage with us digitally, it is becoming increasingly important for organisations to ensure they are consistently developing secure, resilient applications.

A breach of your application security is so much more damaging than a customer journey weakness. Not only could you face regulatory / legal repercussions of a security breach, you can also lose the trust of your customers, trust which could have taken decades to build, lost in seconds.

The problem is, your developers aren’t security experts, and your security experts certainly aren’t developers. That’s not why you hired them. However, building consistently secure and resilient applications means it’s more important than ever to have your developers and security teams working together to educate and upskill each other.

A fundamental challenge can be that the two roles attract such differing personality types. Developers are often tenaciously outcome focused, with a desire to find the most elegant or efficient way to achieve their objective.

Conversely security teams are almost always operating in a spectrum of shades of grey, acting as advisors and brokers of risk with the business. In fact, the technical risk and control side of security is often the easiest and least time-consuming aspect of a security professional’s role. They spend the bulk of their time trying to translate and communicate risks to stakeholders across the business. Building relationships and successfully influencing to achieve an acceptable compromise.

This segregation between the two key teams, coupled with the rapid pace of change delivered to applications often leads to a frustrating game of cat and mouse, where Information Security teams feel out of the loop and are constantly chasing their tails to keep on top of in-flight changes and developers feel like they are unfairly targeted by security teams who often swoop in at the last minute and slow down delivery timelines by imposing a penetration testing requirement which could cause significant rework to remediate any issues found.

I’m sure you’ve seen this scenario play out so many times and felt the frustrations of both sides of the equation. Organisations need to find a way to bridge the gap between the ‘doers’ and the ‘assurers’, this can be achieved with a combination of people, process and technology.

Bridging the Gap 

A great starting point in any improvement activity is to go back to basics. Do the relationships exist between your security and development teams that foster open and productive ways of working?

Do your security team understand the processes that your developers are operating, do they understand the pressures and challenges that your developers face?

Similarly, whilst I’m sure your development team will outwardly agree that security is important, do they really understand what that means? Has your security team taken the time to outline the risks that they are trying to manage, and the obstacles associated with hurriedly organising an 11^th hour pen test?

One great way to communicate the importance of secure development practices is to let your security teams demonstrate how common weaknesses, such as the OWASP Top 10, can be trivially exploited, and also, quite easily avoided. There are a range of vulnerable web applications available online that have been designed to present these common vulnerabilities and can be easily exploited using low cost offensive security tools. Personally, I think the OWASP Juice Shop project paired with ZAP Proxy allows you to demonstrate worked examples of the implications of insecure development practices.

Left-Shift Security 

Whilst establishing the foundations for positive working relationships is crucial, it’s also important to bring your security experts into the development process. If your security specialists are embedded in the development processes it’s easier for them to be seen to be adding value through the software development lifecycle rather than being viewed as a blocker that appears last minute in the route to live.

By involving security teams in the end to end development process you’re giving them the opportunity to assess and advise on items from your backlog / change portfolio that, by the nature of the change, could introduce new risks or trigger additional security testing. This early visibility allows for more proactive planning of where external support may be required and ensures time for such activity can be built into delivery plans and stakeholder expectations on delivery timelines can be openly managed.

This left-shift in your security teams involvement gives them an opportunity to support development teams early in the development lifecycle when making design decisions to ensure security considerations are embedded in the early phases of development activity, as opposed to added retrospectively following a penetration test. An embedded security specialist can also assist your development team in enhancing their software development standards to ensure robust secure coding practices are documented and communicated to the development teams.

Automate the Heavy Lifting 

Finally, after the teams are working well together and security teams are embedded in development processes, it could be time to consider the use of tools and automation. Often there can be a rush to implement automated code scanning or application scanning before the right ways of working and relationships are established.

More often than not with this approach the addition of tools does not add value, it becomes an obstacle that must be overcome. However without the right support from security teams there is a risk that development teams struggle to understand what to do with the outputs of any security scanning, and most importantly there is a lower likelihood that results of scanning are assessed with a view to resolving the root cause of issues identified, rather than repeatedly implementing point fixes to vulnerabilities identified.

In Conclusion... 

With all the right building blocks in place there’s a real opportunity to improve ways of working, establish robust secure development controls and improve security awareness of your people.

Alongside these benefits you might also find that the delivery lifecycle becomes more efficient as the ‘security blocker’ becomes embedded in an advisory and consultative role in the process.

Finally the more security controls you can embed and validate early in the development process, the less likely you are to have to rely on repeated external penetration tests to validate small change activity, this could present a significant reduction in your annual pen-test expenditure.