In the past few years, many large organizations have begun to adopt various secure SDLC methodologies. This is largely due to a number of factors such as the need for the scaling, and the high-cost associated with growth. SDLC methodologies are seen as efficient, and better at identifying and fixing any security related bugs. An SDLC works well in an Agile environment, however many industry approaches have instead relied upon inefficient variants. Let’s take a look at why there is a specific need for organizations to take a new approach for these methodologies.
Most Used Secure SDLC Methodologies
In 2020, there are a number of methodologies being used by major organizations to help them integrate security. One of the more popular ones is developed by Microsoft and is known as SDL. This particular methodology was created to ensure compliance, as well as security. There is an emphasis on following secure practices. Another well-used SDLC methodology in 2020 is Open SAMM. It guides specific security activities under 4 categories which are construction, verification, deployment, and governance.Similarly, the Building Security in Maturity model makes use of 12 separate security practices that are also divided into 4. These include intelligence, governance, SDLC touchpoints, and deployments.
These methodologies are appealing to developers for some obvious reasons, the main one being savings in cost. Since security can be brought in early during the lifecycle, this saves significant costs that could be accrued to do specific design flaws, and security issues that are found much later. However, these methodologies aren’t perfect, and they do have some significant drawbacks that need addressing.
Relevance of Organizational Structures
When we look at the drawbacks of secure SDLC methodologies, we must consider the specific relevance of organizational structures. Clearly we see that these secure SDLC methodologies rely upon division. They go through a checklist of objectives moving from one to another. This is in direct opposition to the more flexible Agile frameworks that most organizations now take advantage of. Most of these SDLC methodologies have a specific timeline that needs to be followed. An Agile approach is based on an ever-changing timeline, and short-term goals. This is why it can be hard for Agile teams to successfully implement these secure SDLC methodologies into their development processes. Aside from this, there are also significant implementation costs to consider.
High implementation costs are one major reason why development teams are reluctant to incorporate secure SDLC methodologies. Every specific security activity can come with an additional cost. Additionally, implementation can also be inefficient for the money that is spent. Organizations must work through an arbitrary checklist and take in the costs, without taking in the full context of the specific activities. This can lead to a ‘tick based approach’ where the relation of the activities is poorly understood. For example, an open source vulnerability scanner may be added as part of a security activity, but it may not be properly used, or the scans may be poorly understood.
Securing SDLC With a Bottom-Up Approach
As we mentioned above, currently, most secure SDLC methodologies make use of a checklist with specific objectives. These are to be completed in a logical order, and this approach can be inefficient when it comes to meeting security goals, and therefore a bottom-up approach should be considered instead. This approach could be more aligned with the Agile way of working. This would mean that instead of looking for things to tick off, an organization could start with their requirements. This would require identifying the specific requirements, and knowing which metrics to use. When it comes to security, there are two metrics which are most notable.
These are the total number of vulnerabilities and the average remediation time. The primary purpose of any secure SDLC methodology is to systematically reduce and prevent the number of vulnerabilities that are present in code. It makes sense that the fewer vulnerabilities are present, the most secure the project is as a whole. The time it takes to fix these vulnerabilities is also important. This is because it becomes exponentially more expensive to fix bugs in post-production. The longer that potential attackers have time with the bug active, the better they could utilize them. Moreover, the ability of an organization to fix these bugs becomes less efficient during the post development phase. They may have moved to other projects by then which take priority.
How Organizations Can Move Forward
The current landscape has changed dramatically within the few years, and organizations must adapt. In particular addressing security concerns must be the top priority. This has partially been done through a wider acceptance of secure SDLC methodologies. However, there can be specific organizational issues with the implementation. This is due to a specific clash between these ways of working.
Many organizations favor an Agile approach in their development since this is far more efficient, and more suitable for modern software teams. However, when it comes to SDLC methodologies, many are specifically designed for the Waterfall approach. In certain aspects, this makes them stuck in the past, and it can cause an organizational clash. Agile is the present and the future, which makes it vital for secure SDLC methodologies to evolve so that organizations can deal with ever-evolving security threats in the best way possible.
It should now be apparent that secure SDLCs certainly require evolution and improvements if they are to meet the demands and requirements of modern development. Organizations are beginning to recognize just how pertinent security is throughout the development cycle, and therefore they need secure SDLC methodologies that line up with their efficient Agile approaches.
5,691 views last month, 1 views today