Managers play an important role in supporting the adoption of SDL in a development organization.
Adoption of SDL requires strong commitment from executive and senior leaders. Without this commitment and support, the adoption of SDL will either fail or not be as successful as it could be.
Executives should demonstrate support for the initiative by clearly communicating the initiative to the organization. They should make a statement at the outset setting out the direction of travel and cultural changes that will be required for SDL to succeed. They should make the mandate of the security program management team clear and explicit and expect success from the team.
This directive should filter down to senior level managers and product heads who should likewise introduce the initiative to their teams calling out the benefits and setting expectations for adoption. Coaching can support these managers in understanding the work of the initiative and how to communicate it with their teams.
Further support must come in the form of provision of resources to support the adoption of the initiative. For example, using SDL may require teams to acquire some automated testing or scanning tools. Managers can support this by signing off budgets and resources required to acquire these tools. Supportive managers will not pinch pennies or suggest lower quality, cheaper alternatives as doing so may demotivate teams and communicate that SDL is not as high a priority. If SDL buy-in is secured from the very top leadership of the organization, it will make it easier to secure funding and resources when needed for its implementation.
Managers can also support by agreeing to delay schedules and release dates should it be required in order to properly meet SDL goals. At Microsoft, Windows Server 2003 was delayed for up to eight weeks in order to conduct and complete a security push. The initial suggestion was (an unfeasible) two days–this is the type of short shrift that security is normally given in many organizations. But seeing that senior managers had bought into the SDL initiative, the security program management were able to secure four weeks and an extension to eight weeks till the necessary security requirements were met. If it required longer, a longer time would have been given. The point is that senior management must support the SDL initiative by willingly and actively delaying releases if it means more time is needed for SDL requirements to be properly and wholly met.
Sometimes the tough decision has to be made to pull a feature altogether. Commitment to shipping quality code means that either an investment is made to bring for example legacy code up to an acceptable security standard, or the feature should be left out altogether.
Training is an vital part of succeeding with an SDL implementation. As such managers can support teams by providing funding for training as well as giving the required time to team members to increase their security awareness and skills.
It will be important to track the effectiveness of SDL execution and this can be done by tracking training attendance and outcomes, threat model production and effectiveness in reducing vulnerabilities early on in the lifecycle and also monitoring for a decrease and rates and types of security bugs found as the development process nears release.