The Strides LTD

The Strides

 

Software development has gone through a radical transformation over the last decade. Where expectations on engineers and budding developers used to be focused on writing lines upon lines of custom code, the industry has morphed into one of the open communities, sharing and reuse. Surprisingly without a negative connotation; this ecosystem of sharing and collaboration across business units, companies and communities, has led to a drastic uplift in productivity, quality and efficiencies in development times. Standard functionality can now be included with a single line of code, whereas in the past developing your own implementation could have led to thousands of lines of additional custom code. Without a doubt, the open-source movement and related communities of dedicated people have been around for a long time. However, it’s only semi-recently that we’re now seeing major organizations actively onboard and involved. It’s clear that when traditional enterprise software vendors start acquiring companies founded on the concept of open source initiatives, it’s a clear signal of the change in mindset across the industry.

 

However, this change in culture and business appetite has also created another interesting conundrum; Security. Whereas organizations used to be able to rely on internal scans, tests and reviews; we’re now faced with a world where most custom-developed business applications use some form of open-source library, and by some reports, these libraries contribute to more than half the lines of code in the entire application. External entities possibly write more than half of the code in businesses’ critical applications. What does this mean? How can we now rely on our internal quality teams and existing processes and measures, to effectively assure us of the security of the applications we’re deploying to service our business? Couple this with the fact that codebases are drastically increasing in size, and we’re now left with the daunting task of testing and quality assurance, from both a functional side, as well as the security aspect.

If you then consider the rate of change and release cadence of some of these libraries; we’re stuck in a never-ending cycle of trying to keep up with the rate of change outside, and ultimately inside our critical applications.
The standard approach of internal scanning and reviews is no longer enough. We must now rely on a suite of internal and external toolsets to help us keep the software we develop safe and secure.
Security is often seen as a blocker or hindrance in any software development lifecycle. That must change across the industry to be effective. When engaged as late as possible, and ultimately blamed for unintended delays or missed deadlines, the relationship between the teams writing our business software and customer applications, and the teams tasked with keeping us secure can be fragmented and fragile.

Security is everyone’s responsibility, and introducing the correct tooling and process into your organization can make all the difference. While not a silver bullet, the methods and technologies mentioned can assist in mitigating the exposure to risk this new development mindset has introduced over time. Endeavour to not turn security into a blame game or finger-pointing exercise, instead empower your development teams, quality assurance professionals, and security reviewers to identify and resolve issues proactively. With the right culture, tooling and mindset, security doesn’t have to be the blocker in your release train; instead, it can be partially automated and brought as early as possible in the release cycle to prevent delays or wasted effort.

Contacts : (+237) 680105784

Email: Info@thestrides.org

Web : https://thestrides.org/

 

 Click here to visit out website