DEV Community: Ksatria Bintang Samudra

The most dangerous code in your app is the code you didn't write

Ksatria Bintang Samudra — Thu, 08 Oct 2026 15:20:51 +0000

Here is a thing nobody tells you on your first day as a developer.

You type npm install, hit enter, and in about four seconds you just invited a few hundred strangers to run code on your machine and, eventually, on your users' machines too. You read none of it. Nobody does.

Modern software is not written. It is assembled. Your app is maybe 10 percent your code and 90 percent other people's, pulled from the internet by name, on trust. And trust, as any security person will tell you, is the whole attack surface.

I come from penetration testing, and I build AI-native now. This is the risk that scares me most, precisely because it is invisible.

When a dependency turns on you

event-stream, 2018. A popular npm package, millions of downloads a week. The tired original maintainer handed it to a friendly stranger who offered to help. That stranger quietly added code that stole cryptocurrency from apps depending on it. Nobody noticed for months.

colors and faker, 2022. Two tiny packages sitting quietly under thousands of projects. Their own maintainer sabotaged them on purpose, pushed an infinite loop, and broke apps around the world overnight. No hacker needed. Just one person with commit access and a bad day.

xz-utils, 2024. This one should have been a catastrophe. Over nearly three years, someone patiently social-engineered their way into becoming a trusted maintainer of a compression library that ships inside basically every Linux server on the planet, then slipped in a backdoor targeting SSH. It was caught almost by accident, by one engineer who noticed his login felt a fraction of a second too slow. That tiny delay stood between us and a backdoor in half the internet.

SolarWinds, 2020. Attackers compromised the build system of a trusted IT vendor and shipped a backdoor inside a normal software update. Around 18,000 organizations installed it themselves, including governments and Fortune 500s. They did everything right and still got owned, because the poison came from a source they trusted.

Now add AI to the fire

Here is the 2024 twist, and it hits close to home for me as an AI-native dev.

AI coding assistants sometimes recommend packages that do not exist. They confidently tell you to install something, a hallucinated name, and you paste it without blinking. Attackers figured this out. They watch for the names AI tends to invent, register those exact packages, and fill them with malware. You asked an AI for help, and it sent you to a trap someone pre-loaded.

They call it slopsquatting. I call it a reminder that the model does not know, it predicts, and your install command does not care about the difference.

How I sleep at night

You cannot read every line of every dependency. But you can stop being an easy, trusting target:

Use a lockfile and commit it. Know exactly what version of what shipped.
Install less. Every dependency is a door. Do you really need a 40-line package for something you can write in 5?
Verify the name before you install, especially from an AI. Real downloads, a real repo, a real history. If an AI suggests a package, confirm it actually exists and is the one you think it is.
Run an audit. npm audit, pip-audit, Dependabot. Free, automatic, and they catch a shocking amount.
Pin and review updates. A dependency bump is a code change from a stranger. Treat it like one.

The quiet truth

The breach that gets you probably will not be some elite zero-day aimed at you personally. It will be a line of code you never wrote, in a package you never read, that you trusted because everyone else did too.

You are not just shipping your code. You are shipping everyone's. So know whose shoulders you are standing on, because some of them are not who they say they are.

Read the label before you swallow the pill.

I am Ksatria Bintang Samudra, an AI-native full-stack engineer with a penetration-testing background and a deep interest in digital forensics, open to remote work worldwide. More of what I build at ksatriabintangsamudra.com.

The hackers thought they were untouchable. The FBI and Interpol disagreed.

Ksatria Bintang Samudra — Thu, 08 Oct 2026 15:15:00 +0000

For a long time, the story of a hacker felt like it had no ending. Someone breaks in from a country you cannot pronounce, drains a fortune, and vanishes. No face, no name, no consequences.

As someone who started in penetration testing and is fascinated by digital forensics, I kept pulling at that thread. Because the ending does exist. It just happens quietly, years later, in a courtroom, after a global hunt most people never see.

Here is who does the hunting, and why it should change how you build.

The most wanted list has a new category

The FBI's Most Wanted used to be bank robbers and fugitives. Now it has a cyber division, and the faces on it are different.

One of the most striking: a woman known as the "Cryptoqueen," who sold a fake cryptocurrency to millions, took billions, and disappeared in 2017. She sits on the FBI's Ten Most Wanted Fugitives list with a multi-million-dollar reward on her head. A fraud that lived entirely online put her next to the world's most dangerous fugitives.

Then there is Evil Corp, the crew behind banking malware that stole tens of millions. The FBI put a bounty on their leader that was, at the time, the largest ever offered for a cybercriminal. Think about that. A man writing malware, hunted like a cartel boss.

And the state-backed ones, operators tied to North Korea's Lazarus Group, indicted by name by the US Department of Justice for some of the biggest heists in history. You cannot arrest a nation. But you can name them, sanction them, and make the world a smaller place to hide in.

This is where Interpol changes the game

A single country's police stop at its border. Cybercrime does not. That gap used to be the attacker's best friend.

Interpol closed a lot of it. Through Red Notices, a global "wanted" flag recognized across nearly 200 countries, and coordinated operations, they turn a local case into a worldwide net. In recent joint operations, law enforcement working together took down thousands of malicious servers across dozens of countries at once. Phishing kits, malware hosts, scam networks, gone in a single coordinated sweep.

And the big ransomware gangs that felt invincible? Agencies like the FBI and Europol have quietly infiltrated them, seized their servers, grabbed their decryption keys, and handed victims their files back for free, before the criminals even knew they were compromised. The hunters started hacking the hackers.

Why a developer should care about any of this

Here is the part that connects straight back to us.

Every one of those takedowns ran on evidence. Logs. Metadata. A transaction trail. A reused username. A server configured just slightly wrong. The reason attackers get caught is the same reason apps get breached: small details nobody thought mattered.

So the forensic mindset is not just for investigators. It is for builders:

Log like someone will need to reconstruct the crime. Because one day they might, and it might be yours to defend.
Assume attribution is possible. The "anonymous" internet is a myth. Everything leaves a trace, and that cuts both ways.
Respect the trail. Good logging, good monitoring, and clean incident response are what turn "we got hacked" into "we caught it, contained it, and know exactly what happened."

This is the exact space I want to build in: the overlap of development, security, and digital forensics. Not just shipping software, but shipping software that can tell you the truth when something goes wrong.

The ending nobody sees

The hacker who felt untouchable in 2017 gets a knock on the door years later. The heist that looked perfect leaves one thread, and a patient analyst on the other side of the planet pulls it.

That is the part I find beautiful. Not the break-in. The reckoning.

So build like you are being watched, because the good guys are learning to watch too. And the oldest lie in cybercrime is the quietest one:

"They will never catch me."

They are getting better at it every single year.

The hackers who stole over a billion dollars taught me how to defend everything I build

Ksatria Bintang Samudra — Thu, 08 Oct 2026 15:07:45 +0000

I am a builder who used to break things. Penetration testing and bug hunting, that was my start before I went full AI-native engineer. And the best security lesson I ever learned is simple: you cannot defend against something you refuse to understand.

So I study the attackers. Not to become one, to stop being easy.

Here is the field guide I wish someone had handed me. The people and the methods actually trying to get into the apps you and I ship, and the one move that stops each of them.

1. Phishing, the attack that skips your firewall

Most breaches do not start with genius code. They start with a convincing email. Phishing does not hack your server, it hacks you. A message that looks like your bank, your boss, or your cloud provider. One click, one login on a fake page, and the attacker walks in through a door you opened for them.

It is boring. It is also how the biggest breaches in history began.

Defense: slow down. Check the sender's real domain, never enter credentials from a link, and turn on 2FA everywhere so a stolen password is not enough.

2. Brute force, the attack with infinite patience

A computer does not get tired. Brute force and credential stuffing just try passwords, millions of them, until one works, usually using leaked passwords from some other site you reused. Your "clever" password from 2019 is probably already on a list.

Defense: long unique passwords (a manager, not your memory), 2FA, and rate limiting that locks the door after a few bad tries.

3. RATs, the quiet houseguest

A Remote Access Trojan is exactly what it sounds like: malware that hands an attacker a remote seat at your machine. Camera, files, keystrokes, all of it. It usually arrives disguised as a cracked app, a "harmless" attachment, or a fake installer. Then it just sits there, watching.

Defense: do not run what you cannot trust. No pirated software, no random attachments, and keep your OS and security tools updated.

4. Ransomware, the hostage-taker

This is the one that makes the news. Ransomware encrypts everything you own and demands payment to give it back. It has frozen hospitals, pipelines, and entire city governments. Pay, and you are funding the next attack with no guarantee. Do not pay, and you had better have backups.

Defense: backups, offline and tested. Not "I think it is backing up." Tested. A ransom note is a lot less scary when you can just wipe and restore.

5. Lazarus Group, when the attacker is a country

Here is where it stops being lone hackers in hoodies. Lazarus Group is a state-linked operation tied to North Korea, and they are not after your selfies. They are after money and leverage, at national scale.

Their record is terrifying: fraudulent SWIFT transfers that drained tens of millions from a central bank, a worm that locked up hospitals across the world, and a string of crypto heists, one of which cleared well over a billion dollars in a single hit. These are not kids. They are a funded, patient, professional adversary.

And the lesson from the top of the food chain is the humbling one: no single trick saved their victims, and no single trick would have stopped them. Layers did. People who verified, who segmented, who assumed breach.

Defense: assume you are a target, even if you feel too small to matter. Especially then.

What studying all of this actually did to me

It did not make me paranoid. It made me calm.

Because once you understand the attacker, security stops being a vague fog of fear and becomes a checklist. Phishing, verify. Passwords, unique plus 2FA. Downloads, trust nothing. Data, back it up. Yourself, assume you are a target.

I build with that mindset baked in, not bolted on, because I have seen the other side. And the single most dangerous sentence in tech is still the quietest one:

"Who would ever bother attacking me?"

They already are. The only real question is whether you studied them first.

I am Ksatria Bintang Samudra, an AI-native full-stack engineer with a penetration-testing background, open to remote work worldwide. More of what I build at ksatriabintangsamudra.com.

I break into apps for a living. AI just made my job easier.

Ksatria Bintang Samudra — Thu, 08 Oct 2026 15:01:44 +0000

Here is an uncomfortable truth from the other side of the keyboard.

I started in security, penetration testing and bug hunting, before I became an AI-native full-stack engineer. So I have spent years thinking like an attacker. And lately, breaking into things has gotten easier.

Not because defenders got lazy. Because everyone started shipping code they never read.

The golden age of "it works, ship it"

AI can scaffold a working app in minutes. That is genuinely amazing, I use it every single day. But "it runs" and "it is safe" are two completely different sentences. AI is very good at the first one and completely indifferent to the second.

The model's job is to make the demo work. Your job, the part nobody can outsource, is to ask one question: what happens when someone malicious shows up?

In most AI-built apps I have looked at, nobody asked.

The same five holes, over and over

I am not going to hand attackers a how-to. But here is the pattern I keep seeing. If you ship web apps, you have probably done at least one of these this month:

1. Secrets in the client. API keys and tokens sitting right there in the frontend bundle or a committed .env. The model happily wired it up. It "works." It is also a free skeleton key for anyone who opens DevTools.

2. Authorization that is not. Authentication asks "who are you?" Authorization asks "are you allowed to do this?" AI nails the login screen and forgets the second question. So user A changes an ID in the URL and reads user B's data. Every time.

3. Trusting the client. Price calculated in the browser. Validation only on the frontend. "isAdmin" sent from the client and believed. The browser is the attacker's playground. Nothing that comes from it is a fact.

4. No rate limiting. Login, password reset, that expensive AI endpoint you pay per call for, all wide open to be hammered a thousand times a second. Your demo survives one user. It does not survive one bored person with a script.

5. Loud errors. Full stack traces, database messages, internal paths, shipped straight to the user. You just handed the attacker a map.

This is not an anti-AI rant

Read me right. I am as AI-native as they come. I pair with AI to ship faster than a whole team. The tool is incredible.

But speed is a loaded gun. AI removed the friction that used to force you to slow down and think. That friction was doing a job. Now you have to do that job on purpose.

So do it on purpose:

Treat every input as hostile.
Check authorization on the server, for every single action.
Keep secrets on the server, always.
Rate-limit anything that costs money or guards a door.
Say less in your errors.

None of this is hard. It is just not automatic anymore. And "not automatic" is exactly where attackers live.

The part that should keep you up at night

The scariest apps I have seen were not built by beginners. They were built by smart people moving fast, who trusted the output because it looked clean. Clean code and safe code look identical, right up until the moment they do not.

So here is the one question I ask before anything I build goes live:

If I handed this app to someone who wanted to hurt me, what is the first thing they would try, and would it work?

If you do not know the answer, you do not have an app. You have an incident waiting for a date.

Ship fast. Just do not ship blind.

I am Ksatria Bintang Samudra, an AI-native full-stack engineer with a penetration-testing background, open to remote work worldwide. More of what I build at ksatriabintangsamudra.com.

How I Ship Production Apps Solo as an AI-Native Engineer

Ksatria Bintang Samudra — Thu, 08 Oct 2026 14:50:47 +0000

I'm Ksatria Bintang Samudra, a full-stack developer from Indonesia. I build and ship real, production web products on my own, React and TypeScript on the front, Node and Python on the back, deployed on Cloudflare. The thing that changed how much one person can ship isn't a new framework. It's working AI-native.

Here is what that actually means in practice, and the workflow I use to ship without a team.

AI-native is not "autocomplete"

A lot of people think "using AI" means tab-completing lines in the editor. That is AI-assisted. AI-native is different: I treat AI coding agents as the default way I plan, build, test, and ship, with me as the architect and the reviewer.

The mental model that works for me:

I own the decisions. Architecture, trade-offs, what "done" means, security, and whether the output is actually correct.
The agent owns the typing. Scaffolding, implementation, repetitive refactors, test stubs, glue code.
Guardrails keep it honest. Clear specs, small steps, and verification at every stage.

The bottleneck stops being syntax and starts being judgment, which is exactly where a developer should be spending their time.

My loop: plan, implement, verify, ship

For every feature I run the same small loop:

Plan in plain language. I describe the goal, the constraints, and the edge cases before any code. A good spec is half the work. If I can't describe it clearly, the agent can't build it clearly either.
Implement in small, visible steps. One concern at a time. Small diffs are easy to review and easy to roll back.
Verify everything. I don't trust output I haven't checked. The build passes, the thing actually runs, the numbers are real. For anything user-facing, I test the unhappy paths too.
Ship and watch. Deploy, confirm it is live, and keep an eye on it. Shipping is a feature; so is noticing when something breaks.

This is also how you move at team speed solo. You are not writing every line, but you are reviewing every line.

A concrete example

One system I built this way is an automated content pipeline. It researches a topic from primary sources, drafts long-form articles under strict accuracy and sourcing rules, de-duplicates its own assets, then generates and deploys the site, all driven by AI with review steps and guardrails so nothing ships unverified.

On the automation side, I have wired scheduled Cloudflare Workers that handle background jobs, like pinging search-indexing APIs on every deploy so new content gets crawled in hours instead of weeks. None of this is a weekend toy. It runs in production.

Speed without safety is a trap

Here is where I differ from a lot of "move fast" builders: I come from a penetration-testing and bug-hunting background. So I don't build a feature and bolt security on at the end. I think like an attacker the whole way through, validate inputs, protect user data, and harden before anything goes live.

AI makes it easy to ship fast. It does not make your app safe. That part is still on you. Treat security and reliability as features, not afterthoughts.

What I would tell someone starting out

Learn to review, not just to prompt. The skill that matters is judging whether the output is correct and safe, not getting a clever answer out of the model.
Keep your diffs small. You will catch more and break less.
Ship real things. A live product with real users teaches you more than any tutorial. My whole portfolio is "here is what I shipped, and it is live."
Own the parts AI can't. Taste, architecture, security, and knowing what good looks like. Those are yours.

If you want to see what this looks like in practice, my work is at ksatriabintangsamudra.com. I'm an AI-native full-stack engineer, open to remote work worldwide, and always happy to talk shop.

Ksatria Bintang Samudra, AI Engineer, Automation Builder, Solutions Architect.