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 lead 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 go-ahead 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.”

Content provided by SD Times and Sonatype