When it comes to talking about Cloud offerings, sometimes there are surprises lurking in the fog.  (Apologies to Bob, and his corny humor)

It won’t surprise you that there is an Intermediary, and they stand to do well. I am speaking of the big cloud infrastructure providers, and their desire to sell you undefined, but discounted software and hosting, through a general term known as Cloud Consumption commitments, AKA “committed use” or “committed spend”

These commitments are an enticing proposition—buy now, pay later, and get a discount.

So, what’s the catch with cloud commitments? Here are a few things you should watch out for:

  • Long-term commitments: These contracts typically last several years, and if you need to exit early, expect to pay an unpleasant termination fee. Once you’re locked in, you’re in for the long haul.

 

  • Auto-renewals: No one likes a surprise renewal charge. Some cloud providers sneak in auto-renewal clauses, ensuring you stay committed unless you explicitly opt out. (ugh).

 

  • Usage monitoring and pricing escalations: Cloud providers will offer monitoring tools to track your usage, but be aware—if you go beyond your committed resources, you’ll likely face price escalations. It’s easy to start with great pricing, only to find yourself paying much more later.

 

  • Hitting your spend target: Oddly enough, the challenge for many organizations isn’t avoiding overuse—it’s using enough of the services to meet the commitment.

In thinking about this, it reminded me of the Gift Card industry.   We buy gift cards because they are convenient, easy to use, and ultimately, expect that we will spend all of the money loaded on the card.  It turns out that a good number of gift cards are either never redeemed at all, or not fully redeemed, with some estimates being as high as 10-19%.  There is even a term for this, called “Breakage”.

 

Here’s where a little bit of strategic thinking comes in. Start by making sure you’re effectively managing budgets and usage projections. But there’s an even better trick—see if the cloud provider offers software you’re already using, or planning to deploy. Many software publishers have favorable agreements with cloud providers, meaning those tools could count toward your commitment. It’s a bit like discovering that your forgotten gift card can be spent on something you were already planning to buy.

This isn’t a perfect solution, but it’s certainly worth exploring. After all, if you’re locked into a multi-year agreement, you might as well get the most out of it. Just like using every dollar of that gift card, the key to cloud commitments is maximizing value while staying informed.

Recently, hackers have targeted Python’s widely used libraries in the Python Package Index (PyPI). These libraries are often only downloaded and installed when a program is run, making it hard to detect or realize that there is a problem.  These libraries also are widely used in a number of program.  In this case, the libraries were downloaded thousands of times, and nobody notice until after significant damage was done.

For commercial software vendors, such a vulnerability would (hopefully) be caught in testing. But for IT managers and shadow IT users that are exploring Open Source tools, enterprise or not? Well, that’s like skating on thin ice with a blowtorch. One wrong download, and you’ve potentially opened the door for cyberattacks—no warning signs or red flags in sight.

I love the open-source software model. I have built a large part of my career on this. But, like everything, there are some challenges, and one of these that is emerging are some new and not so new security threats.

So what might help mitigate some of the risks?

I was inspired by some really smart people in Public Health.  Taking a page from harm reduction approaches used in public health— we could apply similar principles to open source and shadow IT. Instead of saying “No,” what if we tried to adopt a “use safely” approach?

  • Don’t assume safety because it’s free.
    Just because something’s open source doesn’t mean it’s been vetted. To be clear, I think paranoia is probably helpful. Open-source libraries are like free samples—some are great, but others may leave you feeling a bit sick. Remind your teams that due diligence is required especially with open-source software.
  • Harm reduction for shadow IT.
    Shadow IT is here to stay, and rather than play the whack-a-mole game of shutting it down, why not embrace it safely? Encourage teams to innovate and explore new tools, but do it in a controlled way. Use completely segregated sandbox environments to offer a safe place for testing. In harm reduction, safe injection sites minimize risk; in IT, secure environments can do the same.
  • Scan, and realize that scanning probably isn’t enough.
    Insist on using automated scanning tools for every piece of code, and realize that it may not be drilling deep enough into runtime libraries and tools from platforms like PyPI. Just like health officials promote regular testing to prevent the spread of disease, your security team should promote automated scanning tools to ensure no malicious code slips through.
  • Community matters.
    One of the strengths of open source is the community behind it, but this also means there’s no singular authority watching over every package. Get involved in the community where you can. Have your developers contribute and review code. It’s not just about using tools; it’s about being part of a network that looks out for one another. In the public health space, community efforts are critical to harm reduction. The same applies here.
  • Update religiously—Or not. 
    Keeping software and libraries updated is a no-brainer—or is it?  In open-source environments, patches and updates roll out fast. It seems that the hackers in this case managed to commit code to widely used libraries and nobody noticed.   In this case, it probably would have made sense for a developer to wait and see.

We all like learning from other fields—and I think we all have been paying a lot of attention to public health over the last few years.  By applying these harm-reduction lessons to open source, we can balance innovation and security in a way that reduces risk without killing creativity. SAP, Python, or any other platform—it’s all the same story: prevention beats recovery.