The Truth about Today’s Software Development Lifecycle? It’s a Mess!

The software development lifecycle (SDLC) is the framework for developing software and managing it through its entire lifecycle. The SDLC is considered to move left to right, from development to production, in a continuous feedback loop. The overarching purpose of the SDLC, in my mind, is to deliver value to the enterprise and leverage the benefits of your engineering resources.

However, few enterprises benefit as they should from the SDLC because it’s a mess at scale. There are:

• too many manual steps
• too many stakeholders
• too many components

Your developers and engineering teams are retrofitting and fixing things after the fact. Your management lacks visibility or real knowledge of threats in production or how new vulnerabilities and patches need to be addressed.

Now consider the exponential effect of adding additional technology stacks and or other open source programming languages and integrating with legacy systems and managing licenses and dependencies.

In this post we’ll delve into the symptoms of an SDLC mess along with some best practices on how to resolve them.

To do so let’s set the context for these many: steps, stakeholders and components.

Let’s assume that a typical software development lifecycle has 8 Phases: Product Requirements, Solution Definition, Development, Test, Staging, Production, Monitoring and Maintenance. And that there are a number of activities in each phase.

Now add to that multiple stakeholders with differing perspectives create tension with their differing priorities, stakeholders like:

• Internal & external customers
• Domain experts
• Data Engineers
• Developers
• QA
• InfoSec / SecOps
• DevOps / DevSecOps

Further, let’s categorize the typical set of SDLC components (Dev Machines, CI tools, Binary Repos, and Deployment Formats) as a set of self-managed tools that obtain input from a set of 3rd-party, relatively untrusted sources (e.g Open Source Package Repos, Vulnerability Database, Code Repos & Managers). Now let’s consider each of the elements that make up these two categories (self-managed tools and 3rd party relatively untrusted sources) SDLC components.

Self-Managed Enterprise Systems & Tools: for the left-to-right continuous loop

1. Dev Machines — the hardware used for Development. e.g. Linux, Mac & Windows
2. CI tools — the systems enabling the implementation of changes resulting from the continuous feedback loop. e.g. Jenkins, CircleCI, TeamCity
3. Binary Repos — the storage of the enterprise’s ‘artifacts’ or components used in building or deploying the application. e.g. JFrog Artifactory or Sonatype Nexus.
4. Deployment Formats — the formats in which the code is packaged for deployment to any of the environments required in the process for instance, Development, Test and Production. e.g. AWS images, Docker containers, tar balls, OS package formats.

3rd Party Relatively Untrusted Sources: access open source language code and packages, check code and store code.

1. Open Source Package Repos: where your language packages & reside. e.g PyPI for Python, CPAN for Perl, NPM for Node.js, etc.
2. Vulnerability Database: where you’ll find public disclosure of vulnerability information such as the NVD (National Vulnerability Database). There are also applications that will scan your software for current vulnerabilities. e.g. Sonatype, Black Duck, and Snyk
3. Code Repos & Managers: where you store your source code and the source code for a vast majority of open source projects reside. eg GitLab, GitHub, BitBucket

SDLC Mess — Back & forth vs left to right in a continuous loop

As you can now see with so many steps, stakeholders and components, it’s difficult to believe that any one person could grok the entire process, but this what your Dev/Sec/Ops Managers wrestle with every day.

One of the key bottlenecks in this process is the fact that inputs (like open source repos, Github code, NVD info, etc.) don’t enter your pipeline solely at the development stage and flow through to production. Instead, they impact multiple stages of the pipeline, as checks and balances kick in — finding GPL licensed code in Staging; uncovering outdated libraries in Test, or discovering vulnerabilities in Production — all of which force a new dev/test/stage cycle to kick in.

What should be a sequential step-by-step from the left-hand side (development) to the right-hand side (production) in a continuous loop actually becomes a tangle. A tangle of finding the right components, ensuring you have the right packages, managing dependencies, checking for licenses, and so on. In an agile environment you don’t want to waste time or cycles in making changes after the fact.

Suggestions & Best Practices

So what can you do?

(1) Take away the Retrofitting Pain for Engineering Teams — Engineering teams need the ability to track 3rd party dependencies across several platforms and development languages. They need to:

• know when security patches and updates are available;
• know what dependencies and licenses are required;
• be assured that code comes from a trusted source
• build security in the code.

(2) Give Management Better Oversight

• Managers need to know not only which applications are comprised of which libraries and who built them, but also need to be notified as soon as they become compromised. They need to be able to assess risk level at any point in the SDLC, both before the code is shipped, and long after it’s been running in production.

And you can do this by implementing some best practices such as:

• Do it once vs multiple times. In other words security, dependencies and licenses should be included as part of a continuous process and as far to the left as possible in the process. Instead of doing so once in a while as part of an audit, or at a particular later stage in the SDLC.
• Consider the needs of all the stakeholders, list the stakeholders and their key needs, challenges and timelines.
• Have a single place that centralizes information about your licenses, packages and vulnerability info is available for proper oversight.
• Establish a risk model based on threat levels and the impact a security breach would have on your business., Define policies based on your overall compliance and security requirements. This ensures only open source components that fit your risk model end up in production (aka no bad licenses, vulnerabilities, etc).
• Have versioned distributions so you can always reproduce builds.
• Upgrade to new versions continuously and reliably to reduce tech debt (Entropy will always set in).
• Remain competitive by ensuring constant vigilance over product and technology. Furthermore, frequent updates and modifications are the singular means to keep all of your code under control over the long term.

These suggestions have been built from over 20+ years of helping enterprises deploy open source programming languages and seeing the evolution of the SDLC and agile methodologies. (See my suggested best practices here on how to deal with polyglot environments.)