Developer engagement..

Following my recent posts covering application security and patching, another recent hot topic of conversation has been around developer engagement.  Specifically how to ensure developers are fully engaged in the secure development process.

Much like many current patching processes an issue with a lot of secure development programs is that they are still very ‘push’ focussed.

This approach can be successful, especially for organisations with less security maturity.  I have personally seen great uptake in the use of secure development tools and processes through my current teams work.  However while taking the ‘push’ approach can dramatically improve your application security processes, it does have limitations.

These limitations include;

  • It is very resource intensive for the Security Team – they constantly have to ‘push’ to get developers using the tools and processes and on-boarding new applications and developers etc.
  • It can lead to a culture of secure development being the responsibility of the security team rather than the development teams – a culture of taking rather than owning security
  • Things, including entire applications can be missed.  The security team can struggle to know every application and development project that is in the environment if the onus is on them to push security to every application.  This is especially true in more complex, multinational organisations
  • This focus can also lead to dissatisfaction and higher churn in your security team as you will have skilled application security professionals spending large amounts of their time on-boarding developers and applications, and chasing development teams to understand what is being worked on

So, how can we fix this and ensure the secure development practices from training through threat modelling and code reviews are embedded into the development process?

If you read my post on patching, my key thought will not surprise you!  Developers and development teams need to have responsibility for secure development as one of their key objectives.

This is a fundamental shift in culture and responsibilities.  In order to be successful you’ll need to work to drive support from executives as well as the development teams and their managers.  However if you can enable this culture shift, you will have made a huge difference to the uptake and success of your application security programme.

This shift will change the responsibility for ensuring developers are enrolled on the training platform and added to the code analysis tooling into the development teams.  It will also drive the use of the security tooling as one of their key objectives.  There are two key benefits of this approach;

  • Coverage; The development teams and their management will be bought into the benefits and requirements for security.  This will drive the use of security tools and processes for all in scope developers and applications.
  • Enterprise security can focus on security.  The skilled application security specialists in your team will now be able to focus much more on working with the development teams to support secure design and coding.  The secondary benefit of this is that your team will be more engaged doing the work they want to rather than chasing developers to on-board them and their applications!

The second thing I would recommend to support this approach is the creation of ‘security champions’ within the various development teams.  This would likely not be a distinct role, but rather existing developers who ideally have an abiding interest in security.

These roles will have the responsibility of having a strong understand of the required security processes and tooling, along with fostering a close working relationship with the application security team in enterprise security.  These roles could also help with the development of secure coding guidelines and ensuring the application security team understand the way the developers work and challenges they face.

To support the role and working relationship, security champions having ‘dotted line’ reporting to the application security director (or equivalent) should be considered.

The final piece of the puzzle is to ensure your application security team understands the various development processes in use across your organisation.  While the same level of engagement, similar tooling and processes will be used regardless, how they are applied is likely to vary considerably across different development and support styles.

To be successfully integrated the application security team must consider how to best integrate with Waterfall, the various ‘flavours’ of Agile, DevOps etc.  While you do not want a million different processes you’ll likely need a few to cope with the different development and project processes.

If it is not yet in place for your organisation, a good starting point for the SDL (Secure Development Lifecycle) and the steps it should contain is the Microsoft SDL

https://www.microsoft.com/en-us/sdl/

To help you consider variations of your process for different methodologies they also have an agile version;

https://www.microsoft.com/en-us/SDL/Discover/sdlagile.aspx

Let me know what you think of these ideas, and how you get on with implementing them on your organisation, if you are not doing so already!

K

Leave a Reply

Your email address will not be published. Required fields are marked *