Decrease the Costs and Risks of Managing Open Source Languages – InApps 2022

As the adoption of open source languages increases, the challenges of deploying, managing and updating them is exploding. Keeping programming languages up-to-date, free from vulnerabilities and threats while also developing new software that integrates with legacy and polyglot tech stacks has become unmanageable.

Enterprises need to implement a systematic and automated workflow to decrease the costs and risks of managing open source languages. My team and I have defined four phases to Open Source Language Automation. These are the tenets by which organizations and their developers can fully benefit from the full potential of open source languages.

Phase 1: Define Policies

The first required phase defines an organization’s open source language policies. Policies which will need to be programmatically enforced to ensure policy compliance across the entire organization. To do this, companies must define what type of code usage is acceptable at each stage of the software development process and how it can be used by stakeholders in the company. Companies must also set organization-wide open source language policies, version controls and triggers. The key activities that underpin this tenet, or the first phase to Open Source Language Automation, include form usage, package controls, license and security criteria, and culminate in documenting the respective policies.

Form usage comprises existing open source languages, versions and packages that can be used, changed and updated across the organization. It also includes defining trusted sources and usage restrictions based on environment or application. Package controls should detail the recording of vetted packages by languages, detailing the test suite required for acceptable builds and recording the acceptable modifications and sources for packages.

Once those are set, then licensing and security criteria should be defined. Agree on license use by open source languages and environments (e.g. dev & test versus production), as well as the defining of threat levels and any events that will be triggered. The final activity in this first phase to Open Source Language Automation is to document your corporate open source language policies. Make sure to include roles and privileges, expiration of information archives, and who has access to “secrets” — the keys, certificates and passwords required to access shared resources in a secure manner.

Phase 2: Centralize Dependencies

The second phase in Open Source Language Automation is to centralize open source language dependencies. Do this by tracking languages and packages across your DevOps cycle to assess open source usage and ultimately produce a single source of truth for open source languages. You should also gain visibility into the respective language build information across deployed environments such as packages, versions, security and licenses. In order to centralize dependencies, a series of key activities should be executed, primarily around auditing usage, defining terminology and listing package criteria to then document your audit results.

Companies should start by analyzing the usage of open source languages from initial build/test, to deployment, to production monitoring and subsequent updating. By understanding usage, you can then determine what improvements should be made. You can follow by setting naming conventions for open source components, how each stage in the software development process will be termed organization-wide, and trigger events to move from one stage to another.

This phase also determines package vetting or criteria. You’ll need to determine how open source code is vetted and approved to be added to the open source language repository used. Approvals will need to consider environment, stage and use.

The second phase of Open Source Language Automation culminates in recording the results of your audit inclusive of a comprehensive open source language inventory. The inventory will list the runtime information of your open source languages, such as package name and version, security vulnerabilities, and license information.

Phase 3: Automate Your Builds

The third phase of implementing Open Source Language Automation is the actual automation of open source language builds. Companies will receive the immediate benefits of reducing vulnerabilities and increasing application quality by automatically creating builds with a systematic, repeatable build process organization-wide. This phase sets the three lifecycle stages of open source languages: build, certify and resolve.

The first step in achieving a continuous build, certify and resolve language lifecycle is setting the build consumption pace. You do this by deciding how, when and who can update open source language builds. Correspondingly, determine the triggers that force a build update such as time, the severity of vulnerability or major vs. minor language release. You’ll then need to define how open source language builds are certified, and the workflow for vetting and pushing open source language builds to production. Include certification levels per environment (for instance, development vs. production), application or customer use case.

Following the definition of build certification is the definition of the build resolution process. Implement an organization-wide process for how open source language builds are resolved for dependencies, licenses and security. And in order to assess your open source language lifecycle health and optimization, define a minimum set of organization-wide parameters. The parameters should track your open source language consumption, certification and resolution results (frequency, successes, failures) and map against corporate policy.

Phase 4: Deploy and Manage Artifacts

The final phase of implementing Open Source Language Automation is the deployment and management of open source language artifacts. This translates into the automatic updating of all of your test, stage and production servers with the appropriate and latest open source language builds. It also provides continuous feedback into your corporate policies with code-specific open source knowledge that considers security and performance updates.

Achieving these goals will require you to set the mechanism by which you deploy code and how open source language build deployment is enabled — who accesses the builds, who distributes and who pushes to production. You will also report on runtime performance through the monitoring of open source language builds, and implement alerts and notifications based on the open source language policies set in Phase 2 (Centralize Dependencies.)

Going forward, ensure that continuous resolution and updates of open source language builds are realized according to corporate policies and what’s been reported — that is, as updates and vulnerabilities occur. Automatically update test, stage and production servers with the latest open source language builds. In addition, you will need to run continuous build-certify-resolve cycles to improve corporate open source language automation policies. Use code-specific knowledge to improve management, trust and performance of applications.

A Plan for Polyglot Success

Open source languages have been a great boon in many ways to organizations, but they bring drawbacks as well. Drawbacks that must be resolved at scale, across the breadth and depth of open source language use. Success with open source language automation requires not only planning and implementation but also, and most importantly, the involvement of key stakeholders. Then, and only then, can enterprises decrease the expense and risk of using open source languages.

Feature image by Dimitris Vetsikas from Pixabay.