DevOps architecture

Here's the standard DevOps process; some version of this exists at most organizations.

DevOps-BeforeTidelift.png

When it comes to open source packages, most organizations catch problems as applications release into production, and notice new vulnerabilities in production applications. They throw these problems back to the development team for repair:

DevOps-BeforeTidelift-2.png

One missed opportunity, however, is to proactively choose packages that will have fewer problems. This can be due to a lack of tools and process on the development side to look at dependencies, including dependency-related technical debt.

DevOps-BeforeTidelift-3.png

What's going wrong here?

  • Organizations frequently interrupt developer work with scan results from the SecOps side, without addressing why there are so many scan results, or why they are so hard to fix.
  • Bad packages are predictably going to cause trouble. Some packages are old, end-of-life, unmaintained code with nobody releasing fixed versions.
  • Reacting in an urgent "on demand" way, while sometimes necessary, is not always efficient:
    • It can result in band-aids with long-term consequences, like maintaining internal forks of a package.
    • Upgrading a package piecemeal or in a rush can risk breaking production, while rolling the whole stack forward in a planned way with adequate testing might be safer.

Organizations adopt Tidelift to fix this.

DevOps-AfterTidelift2.png

  • Evaluating packages before use on legal, technical, and security dimensions
  • Reviewing tech debt (end of life and other bad packages) and clear actions to take during planning, to create planned work to mitigate it
  • Continuously checking for dependency quality and policy alignment as software work continues — before implementation work, and prior to ops handoff
  • Monitoring the currently-in-prod source code for newly-introduced quality problems
  • And shoring up at-risk packages by working directly with open source maintainers, so less tech debt appears in the future

The result is fewer reactive fire drills, due to actively-maintained packages with fixes available.

This saves our customers time, effort, focus — and reduces risk.

Was this article helpful?
2 out of 2 found this helpful

Articles in this section