Secure Software Development often becomes a discussion topic among security and engineering leadership as quite a few organizations struggle to build programs that can show measurable success across the full portfolio.

Along with the failure to set clear, measurable goals, often there is an insufficient focus on shifting the culture, resulting in an overall lackluster performance in building a Secure Software Development program. Building a Secure software practice is a strategic, multi-year initiative, and if not done right, most companies see it as too disruptive. This gets a lot of focus if it is not producing tangible results. Leadership, in most cases, fundamentally cares about delivering secure software to customers, but usually, it is the security organization that fails to build investment and practice balance that is well integrated and aligned with engineering and business objectives and thus is unsustainable. It is not uncommon to see multi-year Secure Software Development programs demonstrating little value in reducing the overall cybersecurity risk; it is also not uncommon for leaders to question whether the current model is a worthwhile investment.

In this series of articles and blog posts, we will explore new ideas on optimizing Secure Software Development programs to produce the optimal return on investment. The approach here is based on multiple years of experience in building Secure Software Development Lifecycle(SDL) programs and consultation with peers and industry experts. It should be noted that no single approach is the perfect solution; different approaches might work for different organizations or for the same organization at different maturity levels. This blog post will highlight common mistakes and potential solutions of moving security investments to areas that have the most impact on delivering sustainable and measurable value for Secure Software Development programs.

First and foremost, the philosophy must be adopted that security should not pose an undue burden to the organization, security to be effective and successful has to be a partnership, and should be seamless and frictionless, integrating into existing processes without altering them significantly. The security teams must take the burden of security away from users and other teams.

Along with not adhering to the philosophy of partnership, here are some of the mistakes that are most commonly observed in most Secure Software Development Programs.

1 — Not setting a high-level goal for your Secure Software Development Lifecycle(SDL) Program.

“If you cannot measure, you cannot improve it”

— Peter Drucker.

Most organizations fail to set a clear target for their secure software development program. A high-level target, KPIs/KRIs, is your north star for building any program. This helps set the overall direction. In any context, these top-level measurements should be meaningful, easy to understand, and should equate to a measurable reduction in risk. Other targets might support the overall goal, but the top-level target should remain standalone and the only thing that is consistently measured and reported. The one that resonates here is measuring the reduction of the number of exploitable vulnerabilities in external applications; this can be expanded to include internal applications as your program grows. Examples of what is not very useful as higher-level targets are as follows:

• All software developed is going through static and dynamic code analysis and similar targets.

• All vulnerabilities of certain criticality are identified and remediated in specific timelines.

• All applications are enrolled in the SDL program.

• All developers have completed the secure software development training.

Except for the second, all of the above do not directly result in risk reduction and are entirely programmatic. These certainly show adoption but very little in terms of improvement of code quality or practice development. Perhaps these should be measured but not as top-level measurements as an indicator of the success of the program vis-a-vis overall risk reduction. The second one, “All vulnerabilities of certain criticality are identified and remediated in specific timelines,” over time becomes too expensive to achieve.

2 — Over emphasis on Security Training as the key area of focus:

Depending too much on security training for engineers instead of engineering practice and engineering culture creates a false sense of success in the program. Security training for engineering teams as it is delivered today is standalone, and the only purpose it serves is awareness; not entirely useless, but it loses its value over time. Skill development needed for secure coding happens in line with code development. Actual skill development is not in the same timelines as the security training, making security training ineffective and burdensome. On top of that, engineering organization of any size sees enough staff turnover that security training alone does not yield the desired return on investment for the SDL program when the cost of training, management of training, and engineering resource time spent on training is taken into account. Security training, as it is delivered today, should only be used as an awareness tool and not for skill building.

3 — Over-dependence on dynamic and static code analysis.

Static and Dynamic code analysis if not properly tuned, usually produces a large validation workload on security and engineering organizations. Depending on the velocity of code produced, this would be a distractor and not a net value add. These should only be used as a measure to gauge the overall improvement in the security of your code base and not as a regular method of identifying vulnerabilities in code that need remediation action. Instead, the use of security libraries as standard engineering practice should be promoted. Additionally, dynamic and static code analysis is becoming prohibited and expensive compared to the value.

4 — Not enough investment in Threat modeling and Non-Functional Requirements.

Along with Threat Modeling, Non-Functional Requirements(NFRs) are key to achieving higher code velocity and low resistance in delivering a more secure application. Organizations are resistant to Threat Modeling as this is seen as bureaucratic and not agile, however time over time, it has been proven that underinvestment in security in the design phase leads to poor security architecture and poor design choices, which are hard to rectify later and results in security gaps resulting in security debt.

5 — Not leveraging Engineering Practice organization:

Secure Software Development is about cultural change; cultural change is hard, especially if you have two parallel cultural initiatives. Engineering Practice in most organizations establishes how engineering organizations should perform all engineering activities, from source code repository and code management to code development to language support and release management and deployment. This practice already exists in most organizations. Leverage Engineering practice to advance your security goals is a better long-term investment. It aligns with the engineering culture of the organizations and reduces the overall burden.

6 — Not leveraging all technologies available to achieve your overall security objective

The purist viewpoint that all vulnerabilities should be fixed in code has been changing for a while. Not only fixing a one-off vulnerability is akin to whacking a mole, But It is also expensive and results in slowing down the velocity of code deployment. It is also unrealistic and tremendously increases the engineering organization's workload. To achieve the goal of reducing exploitable vulnerabilities in code should leverage a full spectrum of all technologies and capabilities. Technologies like Content Security Policy(CSP), Real-Time Application Protection, Web Firewalls, Servers, Infrastructure hardening, etc. It should all be part of your arsenal. Experience has proven that the use of these technologies results in making an application more resilient to attacks and can also significantly reduce the impact on the application, even if successfully compromised.

7 — Not measuring success:

This is perhaps similar to the first mistake, “You cannot improve what you cannot measure”. To drive a successful, Secure Software Development program, the program's progress and achievement of overall results must be measured and broadly shared within the organization. This generates healthy competition between teams and leadership as they strive to achieve better security. This is not about shaming but rather being open, honest, and direct with where improvements are needed. An insecure application represents a real risk to the whole organization.

In the follow-up blog post, we will present a modified version of the SDL process designed from the bottom up to reduce exploitable vulnerabilities in code.