Securing your SDLC for Open Source Applications

A Software Development Lifecycle (SDLC) is a series of processes or workflows performed to build high-quality software applications. Think of it this way: it describes how software is taken from an idea into something that actual users can use.

Image source

The diagram above illustrates the different stages of the SDLC. The SDLC is vital for software companies and their several stakeholders to better allocate the resources necessary to deliver high-quality applications. It also helps engineers in the whole cycle (developers, DevOps and QA) coordinate with one another.

Now, regarding open source, there are two specific perspectives we want to discuss. The first is using open source libraries in your own projects. The second is this same project being open source itself—meaning it opens itself to contributions from several developers, part or not part of the organization.

In both cases, you are allowing other people’s codes to enter your software’s codebase. In this case, it is important to consider that it enables security vulnerabilities to come in easily. This is where open source security would come in.

If you compare the two, you find it’s easier to catch vulnerabilities manually when accepting open-source contributions from other developers. Before merging any changes done by outside devs, a comprehensive code review can be performed. When using open source libraries, catching vulnerabilities is much harder to do manually. 

What Vulnerabilities Can Be Introduced?

Among all the SDLC phases, vulnerabilities can be introduced in the software development, testing, and deployment phases. These are the phases where new codes can be introduced. Of course, among these three, it’s the software development phase that is most susceptible as most code is added here. Code is also introduced in the QA/testing phase. Normally, automated tests also use open-source scripts. In the deployment and operations phases, the vulnerabilities are introduced in the network mostly (configurations, physical attacks).

So let us categorize the different vulnerabilities according to how they can get in through open-source codes into your projects.

Vulnerabilities from Open Source Contributors to Your Project

SQL injection vulnerabilities/cross-site scripting (XSS)

For example, when an open-source contributor creates a user form, the code used to process user inputs may not be sanitizing those inputs. In such situations, attackers may be able to perform SQL injection and XSS attacks. 

Hardcoded secrets/credentials

Often, this happens because the developer forgets to keep such credentials or secrets in a configuration file. Any attacker who can gain access to these could decrypt any credentials (such as access keys or even passwords).

One implication is that a more sophisticated attacker may perform a “man in the middle” attack in which a hacker sniffs network traffic and captures encrypted communication. If the attacker can easily decrypt such communication (because they probably have the decryption key), who knows what damage they could inflict.

Vulnerabilities from Open Source Libraries

Vulnerabilities that enter through the open-source libraries you import into your codebase are far more challenging to identify. Almost every day, open-source modules get new vulnerabilities as hackers develop more ways to exploit weaknesses in their code.

OWASP keeps an updated list of new vulnerabilities.

How to Secure Your SDLC Helps your Organization

User trust

Your software’s users will most assuredly need to input personal and confidential data while using it—be it in the form of a credit card number or private photos. Poorly developed software can lead to data breaches. In such cases, users stop trusting your company. Look at what happened to Facebook with the Cambridge Analytica scandal.

A secure SDLC will not completely wipe away any threats, but it can strengthen your defenses. Thus, your users will feel more confident enjoying your application’s features without any doubt about their data’s safety.

Policy compliance

Governments have joined the information/data protection bandwagon. From the GDPR to California’s Consumer Privacy Act, we have seen many new regulations that penalize companies that don’t take protecting their user’s data privacy and protection seriously.

While it’s, of course, not your doing that hackers attack your software, it will be your responsibility if you don’t have any credible deterrents against such attacks. Companies that have a fully secure SDLC will always be compliant with these laws.

Information and data are big assets

In the realm of the tech industry, information and data are your company’s biggest assets. Your software product is just a medium for you to harness the power of data for your customers. If that medium is full of security holes, then that data becomes your greatest liability instead.

Conclusion

Creating a secure SDLC isn’t difficult. It might require some adjustment by teams that are not used to it, but it’s a worthy investment. At the individual level, knowing how to develop software securely, no matter which phase you are more suited is very beneficial. Most companies nowadays use security as a major performance indicator.

Here is the featured Image source.