Empower developers for broader role

As companies steadily move toward increased agility, the software supply chain can no longer afford to follow the old assembly-line model: Specialists who once focused their efforts solely on developing code have seen their roles expand to that of generalist. With governance, security and quality assurance professionals less commonplace in the industry, developers now integrate their code in an environment where compliance, security and problem-solving not only rests on their shoulders but needs to be expedited across the software development life cycle.

“It is almost the inverse of the industrial revolution in some way, ” says Brian Fox, chief technology officer of Sonatype, which specializes in software supply chain management. “What that means is that increasingly the developers…are the ones defining the architecture. ” Ultimately that means the developer needs the capability to determine upfront whether the framework is compatible with the license policy, with security and with other requirements.

“Everything gets more real time and the people doing the work have to be empowered to make those decisions, ” said Fox. “They need to be empowered with the information to make the right decisions. ”

That’ s especially critical, he said, because these tasks are essential when software relies heavily on open-source components. The constant evolution of these pre-built third-party components can leads to vulnerabilities, generating risks to application security. Without the proper smart tools to identify code quality, to flag vulnerabilities and to fix them in a way that is policy-compliant — functions that can be accomplished automatically — developers may be unable to track or fix any of these issues and still meet deadlines — if at all.

By being integrated into the feedback loop, the tools create the safety net right from the start. Machine learning can bring results such as a download being intercepted and found noncompliant with policy or a download discovered to be potentially malicious. The same is true for new releases of the components: They may have elements that appear suspicious or originate from a part of the world where such releases are of a questionable nature, Fox said. The feedback message that “this transaction is not characteristic for you ” blocks the download and prevents its use.

The advent of these capabilities highlights even more how inefficient the older model of software development was because, for one thing, those processes customarily used to scan code would focus solely on the custom code, the smaller portion of the code base. The scans would not take into account anything open source, which could account for as much as 80 percent of the code base, said Fox.

To make matters worse, he said, legal, security and other professionals within the organization were usually unaware that this issue even existed — even if the developers themselves did.

“In 2011 or so when we were really starting to solve this problem, we had financial organizations downloading 60,000 components a year and we talked to them and said ‘ we see you are using a lot of open source. ’ They said they weren ’t using open source. They were unaware they were using open source, not recognizing that in the banking training algorithm platform they turned out, 80 percent of that code was open source. ”

In the years that followed, progressive organizations have come to recognize that the legacy model did not work and the best solution was to turn directly to the developer, said Fox.

“Forward-leaning organizations are starting to look at this as proper dependency management, not just picking good frameworks but considering the legal and quality issues, all the way down the dependency stack, ” he said. The idea of bringing everything to the developer ’ s domain in a cohesive, integrated way is finally starting to take hold, he said. This also accepts the reality that open-source libraries can — and should — continue to be a source of efficiency without becoming a source of compromise or threat. It also provides better insurance against common mode failure. Making these better choices upfront means doing less work later, he said.

Fox acknowledges that such a change in the model relies heavily on buy-in from the developers who will, of course, necessarily be taking on those additional responsibilities.

“Developers will be naturally suspicious of anything coming from outside. They have a long history of being burned by bad tools, ” he said.

He believes, however, that developers want to solve the overall problems and that they care about what they ’ re doing. It is a big plus for developers to not have to wait six weeks for the goahead from someone in another building, or perhaps another country, before they can proceed, he said.

And ultimately, he said: “They ’ re going to have less stuff to chase down later. ” z

‘Developers willbe naturally suspicious of anything coming from outside. They have a long history ofbeing burnedby badtools.

— Brian Fox, CTO, Sonatype

Because software supply chain security should feel like a no-brainer.

Continuously monitor open source risk at every stage of the development life cycle within the pipeline and development tools you’re already using.

Lifecycle is made for developers.

You make hundreds of decisions every day to harden your supply chain. You expect interruptions. They’re part of your work. The problem is when they get in the way of your work. We tell you what you need to know to build safely and e ciently — and we tell you when you need to know it. Then we quietly continue our work, and allow you to do the same.

With Nexus Lifecycle, devs can:

Control open source risk without switching tools. Inform your decisions with the best intelligence database out there. Get instant feedback in Source Code Management. Automatically generate a Software Bill of Materials. Enforce open source policies without sacrificing speed.