A Safe Use for Open-Source Code in Custom Development

To better understand what an open-source project is, just imagine a list of your favourite songs you could create on one of the many music-streaming platforms available. You listen to this playlist during the evening…

• Everyone can listen to it (use it);
• The list is accessible, and anyone can subscribe to it (see it);
• A friend named Johnny is fan of an unknown band, and suggests adding one of their songs to the playlist (modify it);
• Another friend, Camilla, asks if she can listen to the playlist during her next party (distribute it).

Because it is developed in a collaborative manner, using open-source code in digital projects attests to a strong community spirit. The open-source code’s quality relies on certain key principles:

• Continuous contributions: developers not only help themselves to open-source code. Every day, they work on available projects and make these projects available to all.
• Peer validation and review: open-source projects can always be improved and are supported by each developer’s contributions, verifications, and optimizations.
• Autonomy and trust: the elements available in open-source code are reliable and already tested daily. These are no dependencies with a self-interested company; projects rely on transparency principles. The community is self-sufficient and can make technological development progress every day.

The largest open-source community lives on GitHub, a platform known for the quality of its contributors and for its number of contributions. True bonds are created daily between the contributors throughout virtual discussions or in-person meetings at key events.

Open-source software is exposed to the same risks as the apps developed by companies, and often, company solutions use open-source dependencies.

That’s why we use the DevSecOps approach, which can mitigate these risks as soon as possible.

Before using any open-source project, our experts analyze its source, its number of contributions, and the activity of the contributors’ group – since most packages are created by several people.

When code is available in open source, it is crucial that a public licence and its type be attached to it. This licence is accessible in a file placed in the project’s root folder. It allows us to identify the project’s source. But it also enables law compliance: indeed, without a licence, the code is copyright-protected by default. Any ill-intended author could contest the use of their open-source code and would have the law on their side.

Some contributors abandon their projects. A project that isn’t updated has more risks of containing vulnerabilities and obsolete libraries.

GitHub’s Dependabot tool can update some of the project’s components if it is configurated with a code repository. Before using an open-source project, we must check the last time it was updated or verify if there are any vulnerabilities associated with the project.

The OWASP Top 10 (Open Web Application Security Project) is the benchmark in cybersecurity. This ranking compiles data on the most exploited vulnerabilities in systems: it is important that each developer know about these risks to identify and correct them.

It is recommended to automate your project as much as possible: automatic build, automatic tests, security scans, licence scans, deployments, hash code reviews… You have to trust automations while also performing continuous verifications. Indeed, wrongly configurating one of these elements could cause an attack on the supply chain or a water hole attack.

With our DevSecOps practices at nventive, we use the Snyk tool. It allows developers to scan the source code, the dependencies, the containers, and the infrastructure as code (IaC) to find and fix these vulnerabilities as quickly as possible.

The peer-review process to approve the use of open-source code also strengthens the use of these open-source projects.

Of course, automation only makes sense if we rapidly deploy the vulnerability fix.

Using open-source code projects has two main advantages: first, it represents an important productivity gain for each developer. Second, since the quality has already been reviewed and passed the test, it gives us a viable solution that saves time and that increases the quality level from one project to another.