Open-source software is a fantastic way to innovate together as a community and share ideas and review each other’s coding for better security. However, the challenge is that as the code is open to everyone — hackers can also review code and then plan and conspire attacks that can be latent in the code until it’s activated or leveraged at a later date when the time is right. Although open-source software can provide an opportunity for the masses, it is essential to stay abreast of the potential vulnerabilities that can lead to attacks. Once you are on the lookout, you can take steps to mitigate them.
Open-source software allows everyone to contribute and improve the code. The source code is in the open, so people can review it and fix it if they find an issue. Generally, as a society, we are getting better at finding common problems, and humanity excels at being creative. As open-source code is publicly available, everyone can view the source code. So, there is the potential for malicious activity. It is not uncommon for those with malicious intent to use the code in open-source software to plan attacks. Hence, the source code, as well as security, is potentially vulnerable to misuse. Furthermore, the vulnerability might not be apparent; it’s like bouncing a laser off a mirror then off a shiny surface to eventually hit the target.
This is a skill in itself and is called attack chaining, the cyberattack chain, or the kill chain. Ultimately, attackers can review the code, and once they have found a way in, they continue to search for other vulnerabilities that can be aligned. Once all the vulnerabilities are aligned, the attack can be executed (the target hit). This form of attack can be complicated; nevertheless, it is widespread, and hackers take advantage of this.
It’s a fact that hackers talk to each other. They trade attacks on the Dark Web and forums. They are followed by others that plan the attack on the platform. So, the challenge is, if a mainstream platform is open-source, the attacker can build the kill chain and then easily practice in their own time. Hence, perfecting the open-source software attack. So, when the time is just right, the attack can be executed flawlessly.
The first challenge is that the code is naked and easily viewable. Second, it can be inspected by those with malicious intent. And third, kill chains can be made, resulting in an attack being executed and a target being hit.
If that was not enough, there is the further challenge of multiple pieces (code snippets) of source code that is open source, potentially being used. These pieces of code can come from a multitude of programmers and may come with built-in vulnerabilities or latent vulnerabilities that are not yet known but may surface in time.
Used maliciously, these can be included in the attack chain and can be used to gain access, maintain access, steal information, or control cyber resources. This misuse or form of attack is widespread. The challenge is that with these snippets of code, and due to some systems containing many sources of code, it is difficult to patch, thus, challenging to resolve the vulnerability.
Additionally, detecting the vulnerability is challenging too. Generally, as a result of the code being nested within an application, finding the problem is not simple. So, this results in an issue that is not easily resolvable.
The reality is that most companies that have had something developed for them would not even know what code has been used or the status of the source code. For example, if the code is secure or if a new vulnerability has been developed. Some vendors evaluate source code for nefarious execution before compiling. However, this code scanning space is still developing. The evasion techniques by hackers can be sophisticated even when code is checked at the time it is compiled, with no vulnerability found. A subsequent update from the code or application could introduce the vulnerability that is manipulated by those with malicious intent — as they had been those responsible for architecting the source code in the first place.
It’s apparent that with the benefit of open-source code come numerous challenges, like those outlined above. Thus, steps to mitigate the challenges should be introduced.
It is essential to take note of the code that you utilize — make a list. By doing this, you have a better idea of the contents — like a list of ingredients, perhaps. The elements that are used in your applications are what constitute the challenge and, remember; they can be chained (as outlined above)
Include the list created as part of your governance approach. Take the time to evaluate new introductions of unvetted technology so that you can adequately assess the security of what is being introduced into your environment. Always, only introduce code that is vetted and checked for vulnerability. Most importantly, never introduce code that is untested, too new, and that you have little confidence in into critical environments. Only stable and tried-and-tested code should be used in these environments.
Use a software code verification tool to check the code before it’s compiled and released. Doing this in a phased approach, with each component checked separately and again once the elements are in unison, can ensure there is no vulnerability when separated or when the code is combined (altogether).
Get an application pen tester to test the applications and a tool that can continuously test against the issues. The attack surface area is evolving, and changes are rapid. Vulnerabilities are likely to emerge as these things keep evolving, so it is recommended that continuous testing should be undertaken (even if the first test comes back clean). Through constant, regular testing, you can defend against a potential attack.
Constructing isolation barriers that create sandboxes helps to prevent attacks that rely on reflection and chain attacks. This works as an effective strategy to keep the components secure.
Open source is a demonstration of how society can collaborate and coordinate efforts globally. Our creative capability can be used for good and bad, and when something like code is publicly exposed, those who have malicious intentions often congregate to exploit. Testing the code continuously and knowing the contents are vital to the defense. The continuous testing cycle is now becoming the norm, and it should be encouraged as a primary part of the ongoing defense strategy.
Featured image: Freepik / Man photo created by Standret
Sponsored by Specops SoftwareSpecops Password Policy not only boosts security, it conditions users to adopt…
IT admins who oversee their organization’s customer service technology may find solutions in new features…
It seems every company, big or small, has moved to the cloud or will soon…
Discord can be a great place to talk to like-minded individuals, or in this case,…
Microsoft holds its fall Ignite event starting Nov. 2. Here’s what you can expect at…