DEV Community: João Pinho

Security at Scale: Our npm Incident Response Story

João Pinho — Wed, 10 Sep 2025 16:20:24 +0000

On September 8th, the npm ecosystem saw what is now called the largest supply-chain compromise in its history. Packages like chalk, debug, and ansi-styles — together downloaded billions of times every week — were hijacked and malicious versions published.

For any SaaS company with Node.js in its stack, this was a moment to pause and act.

At epilot, where we build cloud software for the energy market, we recognised that this had the potential to impact our systems. Here's how we responded.

🚨 First, what happened?

A phishing attack compromised the maintainer of several widely used packages.
Malicious versions were published and quickly spread via transitive dependencies.
The injected code was designed to hijack crypto wallet transactions, but the bigger story is: if attackers could publish once, they could publish anything. Additionally, if attackers could read/intercept our network requests, they would have access to our tokens and thus our platform on behalf of our users.

⚡ Our response — measured in hours

As soon as the incident was announced, our engineering team moved fast. Within minutes of posting the alert in our #dev-security slack channel, we had a small response team come together.
172 repositories scanned: we used GitHub Codespaces to access our centralized codebase and systematically audit our product ecosystem.
451 Node.js projects analyzed: every package.json across our domain groups (auth, billing, analytics, 360-portal, and more) was checked for the compromised packages and versions.
Automation helped: we cross-checked with our internal tooling and monitoring alerts to confirm no production build had pulled malicious versions.

Result: ✅ zero exposure found across all 451 dependency trees.

🛡 Practices that kept us safe

The npm incident highlighted the value of practices we already had in place:

Dependency monitoring with Corge → ongoing visibility into package versions and vulnerabilities across our entire ecosystem.
Masked logs in Datadog → all PII automatically obfuscated, ensuring sensitive customer data never leaks, even if dependencies misbehave.
LLM anonymisation → using Microsoft Presidio, we automatically detect and anonymise emails, phone numbers, IBANs, credit cards, and other PII before any data reaches AI models for our AI-powered features.

These aren't "nice-to-haves." They are part of how we build trust with customers in a regulated industry like energy.

💡 What we learned

Supply chain attacks are inevitable — being able to respond fast is what matters.
Modern tooling makes a difference — GitHub Codespaces let us audit 172 repositories and 451 Node.js projects in hours, not days.
Good hygiene compounds — monitoring dependencies, masking logs, and anonymizing LLM data aren't glamorous, but when incidents like this happen, they prove their worth.

🔭 Looking forward

Incidents like the npm compromise will continue. At epilot, we're committed not just to reacting fast, but to building resilient, privacy-first systems that earn customer trust every day.

Because in the energy market — where trust and compliance are everything — resilience is the real competitive advantage.

Exponential Elegance: Rounding Numbers in JS

João Pinho — Wed, 03 Jan 2024 20:33:39 +0000

As you may be aware, JavaScript and numbers have unique properties that developers originating from other programming languages should be aware of. You can observe this for yourself: just sum 0.1 + 0.2, and you will see what I mean.

Another common scenario is when developers explicitly define numbers as const rate = 2.0. This was common in Java to avoid integer divisions. In JavaScript, you can still definitely use this convention for readability, but it's not required at all given that all numbers are decimals already.

The point of this post is to introduce another particularity of numbers in JS that may not be well-known, which is the use of the exponential operator.

Let's say you are tasked with implementing a rounding function in JS. As you know, Math.round does not provide precision. So a common pattern is, let's say we want a rounding of 2, we could do:

Math.round(1000.230499 * 100) which rounds to 100023
Then you divide it by 100 and you get 1000.23

You could easily come up with a generic algorithm that mimics this. But what if I told you that function only takes 5 seconds to write?

Number('1000.230499e2') = 100023.0499
Number(100023.0499 + 'e-2') = 1000.230499

So a simple rounding function could be:

export const round = (value: number, decimals = 2) => {
  return Number(Math.round(Number(`${value}e${decimals}`)) + `e-${decimals}`);
};

I thought I would share this as it's quite a powerful way to play around with the "comma" in decimals without having to deal with divisions.

Even though AI will do this for you these days, it's always good to know the basics. 👊

[#stayhard] [#keephacking]

Lambda Unleashed: Mastering Massive Data Responses

João Pinho — Wed, 27 Dec 2023 15:35:52 +0000

In the realm of serverless architecture, AWS Lambda has emerged as a cornerstone, offering scalability, flexibility, and efficiency. However, even in this advanced cloud environment, we encounter certain constraints — one being the limit on Lambda response sizes, traditionally capped at 6MB. At first glance, this seems reasonable. After all, APIs are generally not designed to handle or return voluminous amounts of data. The principle of keeping responses lean and efficient underlines much of our best practices in API design.

But what happens when the unexpected occurs? When, despite our best efforts and designs, the need arises for Lambdas to return larger payloads? It's not always about wanting to push the boundaries; sometimes, it's about adapting to them. In this blog post, I aim to delve into the nuances of scenarios where larger Lambda responses are not just beneficial but necessary.

Large Response Middleware

This middleware allows a service to log and save large responses to an S3 bucket, enabling developers to investigate the causes of such large responses. Furthermore, this middleware accepts a special header that allows the rewriting of the response with a $payload_ref pointing to the large payload stored in S3, enabling clients to recover gracefully.

Use Case

An internal application of this middleware at epilot involves a service that constructs a Programmatic Runtime containing a large {} variable context. This context is then used to generate sophisticated Document Templates. Our clients leverage these templates to dispatch Emails or Attachments to their end-customers. Although the resulting context may be substantial, its necessity is unquestionable for thorough exploration and real-time evaluation of the compiled template against the context.

Limitations

This work is a great all-in-one solution for one specific lambda use case:

API Gateway with Lambda Proxy Integration

Although, while we at @epilot use this pattern a lot, it's by no means the only way Lambda is used.

The same 6MB response limit applies in all Lambda use cases. Just to give some examples that are not covered by this middleware:

Lambda function URLs
Lambda in Step Functions
Direct Invoke via Lambda API
API Gateway Lambda service integration
Lambda@Edge

Since the 6MB limit applies anywhere, we could build and publish something more generic that works for all Lambda use cases (not just this one).

The good news for the community is that, we've an open issue for that aws-lambda-utility-middlewares/issues/1. And we may put some more work on it during the near future. Contributions are also more than welcomed 🙌

How it works

For handling a Large Response, clients must request with the HTTP Header Accept: application/large-response.vnd+json. This custom MIME type signals consent to receive a large response payload when required. The format of the response body for this MIME type is:



{
  "$payload_ref": "http://<s3 file reference link>"
}

Should the client specify this MIME type, the Lambda bypasses logging an error with Log.error. Instead, it restructures the original response, incorporating a reference to the substantial payload now in S3. The modified response also carries the HTTP header Content-Type set to application/large-response.vnd+json.

Absent this MIME type, the Lambda logs an error using Log.error, leading to a response failure due to the oversized body.

Configuration Options

Supported Parameters:

Parameter	Type	Description
thresholdWarn	`number`	Warning threshold level (percentage of `sizeLimitInMB`), e.g: 0.80
thresholdError	`number`	Error threshold level (percentage of `sizeLimitInMB`), e.g: 0.90
sizeLimitInMB	`number`	Maximum allowed size limit in MB, e.g 6
outputBucket	`string`	Identifier or name of the output S3 bucket
groupRequestsBy	`function - mapper`	Function to group requests, based on API Gateway event V2. Defaults to 'all'

Example Usage:



withLargeResponseHandler({

  thresholdWarn: 0.85, // 85% of the limit = 5.1MB

  thresholdError: 0.9, // 90% of the limit = 5.4MB

  sizeLimitInMB: 6,

}),

Repository

Explore the repository and npm package here:

Thank you for reading! If you found this post insightful, please don't hesitate to show your reaction and support.

#stay-hard #keep-pushing-the-limits

Wishing you a Happy New Year's Eve! May the year ahead be filled with innovation and success.

Using React within Your Svelte Applications

João Pinho — Mon, 19 Jul 2021 09:22:48 +0000

What is this post about?

This blog post is about, how can you inject your React components within your Svelte Application. A couple of reasons for this, but not limited to, are:

You have a big codebase in React and you want to try a new piece of your Architecture in Svelte without jeopardizing all that you have built over the years
You want to support a hybrid model so that your ReactJS Developers have time to keep up with Svelte until they finally move over
You really need to integrate with this amazing ReactJS library and they do not have a Svelte version of it

And as a final note, let me just answer the question that is on the back of your head:

You can do everything that you do in React in Svelte and more!

How can you build Svelte and React Side-by-side?

You will need at least 2 things:

You need to install react and react-dom React lives on the browser and Svelte compiles on the server, therefore you will need to render your React within Svelte onMount handlers
To help you with this, I’ve built a nice abstraction and this is how it looks:

<script>
  import Button from "@material-ui/core/Button";
  import ReactAdapter from "./utils/ReactAdapter.svelte";
</script>

<ReactAdapter
  el={Button}
  class="mui-btn"
  children="Hello"
  variant="contained"
  color="primary"
  onClick={() => alert("hello world!")}
/>

<style>
  /**
   * Styling a React Component from within a Svelte Component.
   */
  :global(.mui-btn) {
    margin: 20px;
  }
</style>

As you can see above I’m using the ReactAdapter. That adapter is an abstraction that basically, given a React component, expands all its props into the final rendered React component without you having to care how to inject the React component itself in Svelte.

For the full article, including a deep dive into the implementation of ReactAdapter check this Medium article.

The repo with docs and the code is here at jpinho/svelte-react