Commitment Should Show

It has happened again. A software library was recently found to be working as an open door for attacks to a massive amount of products that have it within their foundation. We have a name for this: supply chain attack. We're referring this time to the exploitation of polyfill.js. To those learning about this news just now, the domain that software products use to embed this library, with the purpose to make modern functions available on older browsers, has been sending malicious JS code to such products, which has resulted in users being redirected to unsolicited websites. Around three weeks after the news broke out, more than 80 thousand web pages still use the library. They use it even as the original author urged projects to remove polyfill.js. What's more, it's in use even as this same person says modern browsers can take care of what the library was made for.

Now, we want to talk about an event prior to the above attacks, as we think it's key to understanding a major concern surrounding supply chain attacks. So, polyfill.js had changed ownership in February, 2024. And upon realization of the disparity between the creator's comment ("[...] remove [the library] IMMEDIATELY") and that of another important person previously involved in the project ("I've been in discussions with Funnull for many months and they will be the new maintainers and operators of the [library's] GitHub repo [...]"), users started to have questions. What to do? And just who are Funnull? Indeed, this last question has led to worrying discoveries. Reportedly, while the firm says it's from the U.S., its site is in Mandarin, the addresses where it claims to have offices are bogus, and its actual location might be in the Philippines. Browsing its website, people have noticed that the firm fleetingly mentions a privacy policy which no one can locate, and states that users themselves should regularly check the service terms to learn of any change to the latter. The ownership change was done carelessly, without transparent communication regarding who the new owners and what the implications for users shall be.

The above begs the question: Who are the ones maintaining the most common building blocks of modern software? You know the joke of it being just one unsung hero(ine) taking care of the one building block which, if tackled, would cause the whole edifice above it to collapse. A previous post argues that this, though a funny joke, is kind of close to reality. The Linux Foundation and The Laboratory for Innovation Science at Harvard found that for about a quarter of 49 of the most used free and open-source libraries just one developer had contributed to more than 80% of the given library's lines of code. And how committed to security are these and the other most used projects? The aforementioned research shows that many of them are maintained from individual accounts instead of organizational accounts. The former have less granularity in regards to controlling permissions and publishing than the latter. Further, one more observation that can be made is that the vast majority of the most commonly used libraries do not participate in the Open Source Security Foundation's Best Practices Badge program. This program stems from The Linux Foundation and is an opportunity for development projects to openly share their degree of compliance with many security requirements. While their not participating in it does not necessarily mean that they do not indeed follow the expected best practices, there is room for doubt. Honestly, given that our software, as it is widely known, is made up largely of open-source indirect dependencies (i.e., packages used by the packages we use in our project), it's only logical we want to know how safe these dependencies are. We need transparency, i.e., projects being open and honest about their security practices, risks and incidents, if we want to be able to counter supply chain attacks. What's more, we ourselves, granted that our project may be part of some other project(s), need to start being transparent, or maintain or refine our transparency.

All this may seem overwhelming, but clearly it's only fair that each of us acts in favor of fellow developers', and ultimately end users', surety of our security practices proactively preventing successful attacks. We can help you secure your software by offering you the best AppSec techniques and tools to manage vulnerabilities across the SDLC, not only related to your code but also to the status of the third-party code you use. Contact us.