Click to learn more about author Rami Sass.
Every new reign begins with change. Organizations are relying more heavily than ever before on open source components to work faster, smarter, and more efficiently to meet the changing development environment.
The heavy reliance on open source generates many “hows”, bringing to the fore a multitude of questions that fall in the intersection between three organizational parameters: authority, visibility, and culture.
Jointly these three musketeers of open source introduce questions about who the decision makers of an open source policy are, why visibility is necessary when using open source and how it is achieved, and queries to do with a development culture that not only gives way to a formalized use of open source but really gets into what it means to manage vulnerabilities written by anonymous contributors.
Flying Without a Safety Net
Open source components comprise 60-80% of codebase in modern day applications. Despite these numbers, many organization are still not in the habit of implementing an open source policy that guides their developers how to choose open source components based on vulnerability severity, license type and more.
Now, using open source in an agile production environment is a necessity and a life saver. No developer will deny that. But in the race to achieve production goals, developers often forego issues of security and license compliance, unknowingly adding a whole lot of headache (if not much worse) down the production line. As Honeycomb.io CEO, Twitter personality and all-around mouthpiece for Bay Area startups, puts it: “Lines of code are lines of liability, people. Tattoo that shit on your manager’s eyelids.”
If that is not enough, the familiar Equifax headlines about $275 million in breach related costs should be a case of enough said. Because detecting vulnerable open source components in the preselection stage and blocking them from entering your software will cost you much less time and money than the results of a well-executed breach.
Let’s Talk Authority
If your organization is of the “let them be” variety, your junior programmers are probably enjoying free reign of your product and introducing every open source library and component they see fit. There is likely little structure or method to the madness. That would fine if it didn’t put you at risk of one of those vulnerable components getting hacked.
Since it does put you at such risk, a governance policy is needed.
The idea is not to strip programmers of their power to creatively and imaginatively code away, but rather to rein them in and stop them from choosing affected components to begin within.
In a seemingly paradoxical way, emerging voices in the programming space are saying that tightening the reins actually gives more freedom than less. It’s a classic case of choice overload. And without the ability to get information about a component pre-pull, there is little way for a programmer to know whether he’s inadvertently causing himself a world of vulnerability related headache down the line.
A governance policy should therefore be constructed by executives, whilst weighing in those voices of the programmers doing the actual work. A policy ought to be consistent and uniform, answering questions of detection, monitoring, location and remediation of open source usage.
Guess Who’s Watching?
Governance begins with visibility and continues on to accountability. Simply, you can’t be accountable for what you do not know exists.
Gaining visibility of the open source components in your codebase is therefore a first order of business in the move towards an open source policy. Software Composition Analysis (SCA) are the tools of choice for this purpose, detecting the open source components in your software in real-time, including all dependencies, and therein shoring up the vulnerable one.
Open Source Culture in Bloom
An open source culture starts with welcoming open source usage into a product in an official and formal way. It is the antithesis of turning a blind eye and a deaf ear to what your programmers are doing.
This third musketeer, perhaps the most brave and brazen of the three, digs right into the heart of what open source is all about. The ownership dilemma. Open source components are reusable components written by third party developers, someone unknown and outside your organization, and integrated into your software. The question of ownership gives rise to the idea that a programmer must take responsibility for the components he uses as if they were code he had written himself.
Developers are not generally inclined to take ownership of the open source components they use. Simply, it’s an issue of not viewing someone’s else’s work as if it were your own. More pertinently, it’s a matter of not viewing code as a holistic unit of responsibility; jointly the proprietary code written in-house and the open source code written by an unnamed author. With open source being the main building block of your application, not taking end-to-end ownership of it the way you would of your proprietary code exposes you to unnecessary security and compliance risks.
An open source culture in the full sense of the word begins with ownership, goes through blocking of vulnerable components before they enter your build, and ends with a safer and more secure product.
What’s Between the Musketeers and an Open Source Policy
These three musketeers are the cornerstones of a formalized open source policy. They are the foundation for a move from free range open source usage to a transparent, monitorable, accountable use of open source.
This change is happening and it is happening fast. Companies are adopting open source at the speed of light as the understanding is sinking in that open source usage is happening anyway so better be methodical about it then run the risk of usage without a safety net. Formulating a policy around the new wave of open source usage is, ultimately, a matter of getting on the bandwagon before the wagon gets hacked.