Companies are made up of what they build, borrow, and buy. On the software development front, Sonatype's tools help with two major issues: what you build (software) and borrow (open source code). But what about the things you buy? It's part of a wide umbrella in organizations known as "procurement," an area with an all-too-common lack of understanding and oversight.
A multi-part interview with Sonatype VP of Security Mike Griffin about this issue, starting with an introduction to the topic.
How are security and procurement connected?
Mike: First, think about partners or vendors and a technology or service. It's not much different than bringing on an employee or contractor. We've got to do background checks to help make sure they don't have a shady history. After all, you're not going to bring on a new CFO or someone in finance who has a history of fraud. Similarly, we want to avoid vendors who have poor security hygiene.
You want to make sure that the partners that you bring are healthy and have a track record of delivering on their promises.
Second, is what you're purchasing either a highly integrated technology or a service that hands over sensitive information? If so, it's important that the partner and solution together have been reviewed to make sure that we are going to get the quality we expect. That they're doing the right things with our data.
Just like a new hire, you're looking at abilities, experience, and knowledge. After all, if we hand them crucial customer data, we want to be sure that they're going to protect it equal to or better than we can.
Third, we also want to think about culture. Think about bringing on an employee that doesn't fit with our culture and doesn't fit with our values. The same thing goes with vendors, there are certain vendors out there, that you may not want to have a relationship with because they:
Have unclear or risky practices
Are difficult to work with
Have contracts that put you at risk
After all, signing up with vendors who say "we’re not liable for anything" with critical customer information is putting your organization at risk.
Whether you buy it or build it, it's important to make sure that you have a process that allows you to bring in to analyze the fit, form, and function.
Considerations like this also give you the opportunity when something new is proposed to pause and ask: "do we already have a service or a piece of technology that does this?"
What are the dangers?
When you have low-maturity procurement discipline, you may wind up with a no-technology-left-behind situation, without any kind of filter. Dangers here include orphaned systems, lack of sunsetting, overt complexity, and licensing problems.
Let's say an employee bought something, they use it once or for one specific thing. Yet it's still running and we're still paying for it. Who owns it? Orphaned tools and services like these lead to cybersecurity problems, unnecessary expense, and other types of risk.
Lack of sunsetting
Unused or outdated services without a system to take them offline can leave important information beyond your company borders. Important data left in the hands of that technology, vendor, or service leads to still more risk.
One form of technical debt is a tangled, unmanaged, and overlapping environment, or sprawl. This is because the more moving parts you have, the more you have to manage those vendors and solutions. All those mean more chances for issues to get lost in the confusion, more chances for error.
This last issue happens everywhere but especially in places where there's either no procurement system or the steps in place are too laborious. Developers for example will often go and grab an open source program and start using it without looking at legal obligations. Nothing against open source, but some have limits. Some free for use but not in a commercial environment.
You could have lawsuits as a result of the inappropriate licensing.
How does bad procurement create technical debt or rework?
Mike: There's a whole variety of different tech debt types out there and bad procurement can certainly contribute to the problem.
Sometimes staff will buy things that are used as a one-off or a temporary fix that ends up getting hard-wired into your process. Then, when you start trying to untangle these tools and services, you have to start asking hard questions like:
Who owns this?
What is this running?
Is this even necessary?
One direct example I've seen is finding a strange device in your server room or a networking device being held up by a cable that no one uses anymore. If you don't have a process that assigns ownership, you wind up orphaned equipment and services.
If there's no ownership, no monitoring.
Then one day maybe two years down the line, you see that someone bought this appliance, software, toolset, and no one knew. Even worse, sometimes it's running something that’s now critical to the organization.
Another issue is outdated software. As you dig into the tools and processes, it's common to find a service that hasn’t seen important upgrades. So rather than doing gradual, incremental, and regular updates to your devices and services, suddenly there are major updates?
Now the difficulty is compounded and multiple, major updates can take serious downtime and re-work. It can happen if no one is tasked with handling the service.
Consolidation is also tech debt. I've seen cases where there's no understanding of available tools, so you wind up buying five or six or seven technologies that all do the same thing, where I only need one.
In our next segment, we’ll talk through how companies can tackle bad procurement.