Finding Hidden Code Clones in npm,
a gem ✨ or a curse 🐞 ?

Learning from reviewing 1,716,061 JavaScript packages on npmjs registry. A thread 🧵 

The following are my highlights & interpretations of recent academic research article titled "What the Fork? Finding Hidden Code Clones in npm" (Wyss et al,. 2022)

The research sheds light on a copy&paste phenomenon in which devs re-upload code to new libraries. Why is this bad?

Well, if you take bits and pieces of code from other libraries, or say, StackOverflow, and you glue it with your own code, or just plainly re-upload that as a small library, then you risk the chance of also copying insecure and vulnerable code that is now essentially untracked 😲

It beings by highlighting: "A shrinkwrapped clone is a package which duplicates the code of another package without any indication or reference to the original package"

It identifies (1) identical clones - copy/paste of existing packages and (2) close clones - semantical changes

So, what was found?

Based on a subset of the packages hosted on the npmjs registry, the findings were:

✅ 6,292 clones
⚠️ Up to 2,159 of them relied on vulnerable and outdated dependencies

Here's a code snippet of the npm-registry-fetch npm package. It is downloaded more than 4 million times a week.

This code shows a patched version of the library, found to be vulnerable to sensitive information exposure https://security.snyk.io/vuln/SNYK-JS-NPMREGISTRYFETCH-575432

guess which package is vulnerable??

Nah, you didn't guess it so let me help :-)

Apparently, there's an npm package under a scope namespace called https://www.npmjs.com/package/@evocateur/npm-registry-fetch

✅  It has 333,292 downloads a week
✅  It was last published 3 years ago
❗ IT DOES NOT INCLUDE THE FIX APPLIED TO npm-registry-fetch

The fix to npm-registry-fetch was disclosed on July 7th, 2020, but given that the scoped shrinkwrapped clone hasn't been updated for the last 3 years, it is now effectively vulnerable to the same issue.

But guess what? scanned like npm audit won't tell you that :(

So, what does this teaches us about the entire npmjs registry of JavaScript packages encompassing almost 2 million open source projects?

✅ About 10.4% of packages could be considered clones
✅ Estimated at about 178,470 npm packages at the time of the research

Is there any real-world usage impact?

It seems that the 6.7% of cloned packages found has a relatively low number of downloads per week.

For example, 21 out of the 348 of the identical clones packages have more than 350 weekly downloads. Some users are definitely downloading.

What's the impact of security vulnerabilities to shrinkwrapped clones?

62 out of 348 npm packages of identical clone type contain vulnerabilities that are not present in their most-up-to-date counterparts. It grows to 2,304 out of 5,944 for close clones npm packages (!)

Shrinkwrapped clones of npm packages pose a real threat to the npm ecosystem.

The identified package count are somewhat small in comparison, and the downloads count are small too. Yet the high number of vulnerable clones is alarming.

Great research! https://web.cs.wpi.edu/~ldecarli/docs/papers/icse22-shrinkwrap.pdf 👏

26 least favorite things in #DevRel 🥑 🙈 

1️⃣  Product marketers do not understand developer outreach and don't validate their messaging frameworks with developer advocates, which results in ineffective marketing (by @tessak22)

2️⃣ Explaining what you do as a DevRel to someone outside DevRel (by @SarahJaneMorris)

3️⃣ Getting pulled to any and all activities and discussions just because you are "DevRel" and no one fully comprehends what this actually means (by @dev_christina)

4️⃣ Defining KPIs in Developer Relations (by @dnsmichi)

5️⃣ Cross-departments misunderstanding the different activities and think it's "just a job" rather than a collection of activities and roles under the DevRel umbrella (by @vtimd)

6️⃣ Tracking the metrics that funnel up to all activities done by developer advocates and that are needed in order to convey effectiveness (by @brandontroberts and @dmessing)

7️⃣ Folks in DevRel who maintain an image of being pure from seemingly muddy work like customers, money and interaction with sales, marketing, and alike (by @mattstratton)

8️⃣ Quitting DevRel may have some unexpected monetary and reputation impact due to pre-confirmed speaking engagements incurring travel costs and handling cancellations (by @shehackspurple)

9️⃣ As a DevRel you mostly have an outwards impact as an individual contributor, and the impact is very much based on your own persona and community involvement. This makes you effectively "irreplaceable" and adds difficulties for others to fill in for you.  (by @DivineOps)

🔟 Planning activities in advance, such as public speaking engagements for conference talks. Mostly hard due to the inherent nature of uncertainty involved with these activities (by @mattstratton)

1️⃣ 1️⃣ Accounting and communicating the return of investment (ROI) of your speaking engagements (by @davidgsIoT)

1️⃣ 2️⃣ Taking DevRel activities for granted (by @taylor_atx)

1️⃣ 3️⃣ Cross-department dependencies on other teams - SEO,  Technical Writers, Design, Social, and other supportive functions in Marketing (by @siddharth_hacks)

1️⃣ 4️⃣ The constant struggle to prove the value of DevRel (by @erikaheidi)

1️⃣ 5️⃣ Juggling a lot of projects in parallel and incurring the context-switch involved with these. (by @ASpittel)

1️⃣ 6️⃣ Having to deal with harassment and personal safety issues (by @ASpittel) 

1️⃣ 7️⃣ Being taken less seriously as an engineer due to the DevRel role/title which folks often read as "marketing" instead of anything more technical (by @ASpittel)

1️⃣ 8️⃣ Expense reports (by @ChloeCondon)

1️⃣ 9️⃣ It's mostly a "lonely" job in the meaning of fewer shared experiences and connections across the team due to the ecosystem and laser-focused nature different folks in a DevRel team have (by @rothgar)

2️⃣ 0️⃣ Connecting with other developers on virtual events is hard (by @DewanAhmed)

2️⃣ 1️⃣ High workloads. Too many tasks, too little time to fit them in  (by @mooreds)

2️⃣ 2️⃣ Communication part of DevRel is real but not always taken as legitimate value by others. For some, you're just a robot reciting marketing or sales talk of the company (by @tracypholmes)

2️⃣ 3️⃣ Having to get executive sponsorship for projects in order to support a strategic initiative (by @seanfalconer)

2️⃣ 4️⃣ Keeping up with the pace of tech (by @DonSchenck)

2️⃣ 5️⃣ Prioritization of all the different ask, activities, and learnings (by @ThatJenPerson)

2️⃣ 6️⃣ Struggles in balancing the developer advocacy aspects of collaborating in the ecosystem you're in with the obvious product overlap (by @mtaulty)

This thread mostly recites all the great insights shared by folks replying to @tessak22's original tweet on this: https://twitter.com/tessak22/status/1491400606233546752?s=20&t=TuxQwVXlCy_BWRtjXWs3xw

Top 26 least favorite things in Developer Relations

Here is how I launched a program to educate, inspire and accelerate opensource software for students and underrepresented groups.

It's a story about how positive thinking, and what seems to be the "law of attraction" in the Universe, helped manifest my idea about open source into real-world impact.

2 days ago I wrapped up the program that I had set my mind on to promote education about opensource software.

I’m still high on the incredible journey this was and wrote some of my thoughts down.

Going into 2022, I wanted this year for me to be about driving meaningful impact for the open source software movement. 

It seemed unthinkable to me that Computer Science students or developers already blended in the industry don’t have a GitHub account, or never took part in collaborating in open source projects.

I wanted this to be more about collaboration and opening participation to newcomers who hadn’t yet felt the rush of getting their pull requests merged. I also wanted to spend more of my time with underrepresented groups.

Earlier this year I reached out to bootcamps and meetup groups such as @shehacks_ke which promote cybersecurity awareness for women in Kenya. I did a live hacking presentation with those lovely humans.

It felt great to share my knowledge and empower others.

I wanted to do more of this, but also more about open source software in general. How do I go about doing that?

I ran a few ideas in my head. 

One was about running some sort of Open Source Day at Universities and planning a schedule where we learn, practice, and celebrate open source collaboration. I initiated a few discussions with folks I knew but it didn’t move anywhere. It was hard to get their buy-in to this.

At work, I was also very busy, in a good way. That, and with all of the time I spend participating in communities, I barely get my 6 hours of sleep anyway. 

My idea almost faded away… until one day

One day back in February, I went to do some work from a small co-working space in my suburb city. I don’t live in the tech valley of Tel Aviv. I noticed that most of the desks were occupied by students. 

I had a chat with the venue owner and he shared with me about his attempts of creating a local community for folks in this suburb city to help each other, connect them, and help them succeed in their career journey.

This was it. I knew it.

Thoughts become words, words become actions, and actions become reality.

I proposed the idea of running a workshop about open source software. He immediately smiled and said: “MADNESS! Let’s do it!“.

That’s all it took.
He's in.
I'm in.

Now what?

In February, I started drawing out the concept for a program that would come to span over 4 weekly classes. I created a syllabus to bring the students up to date with collaborating on open-source software.

But we need some guiding principles if this was to live up to my idea.

I had 2 rules I set out:

- (1) the program needs to be inclusive, with specific success KPIs for inclusivity around gender and underrepresented groups

- (2) the program needs to be practical and hands-on, and not require any prior knowledge of programming

This program came to be #ReadyCodePush.

I drew up a logo. I like the GitHub contribution squares reference.

But what will I teach?

4 classes of 3 hours teaching this:


- Class 1: Open-source software and the GitHub Developer Platform

- Class 2: Software development on GitHub’s developer platform

- Class 3: Automate software delivery with GitHub Actions

- Class 4: Securing open-source software with Snyk

I never imagined the content to resonate so well.

I saw students creating their first GitHub user, earning their first green contribution square, creating a profile README, creating their first repository, forking and opening pull requests. 

They went on to configure GitHub Actions jobs, creating a Snyk account and seeing vulnerabilities come to life for the first time. 

They were all hooked on open source now. Some of them were even hooked on cybersecurity and explore it as next steps for them

One of the students, Sagi Weizmann, is a full-time employee doing full stack development. He volunteered to run the DevOps introduction in Class 3. What a hero!

He shared his experiences, practiced public speaking, and took an active part in this program.


I was proud, impressed, and thankful.

Together with #HubAshdod, the co-working space that provided the venue and yummy pizzas, we launched the program about 3 weeks ago.

We had 34 students sign-up, regularly attended the in-person classes from 6-9pm, and actively participate. 

We concluded the program this week with the first cohort 🎉

IT WAS AMAZING.

Now it’s time to reflect, assess, and re-group for the next cohort!

Read through this far?
you deserve pictures from the workshop :-)
