The security bill nobody in cross-border e-commerce budgeted for
Every cross-border seller I know is now shipping software, not just products. That’s the quiet shift of the last eighteen months: a Shopify merchant bolts on a custom returns portal, a TikTok Shop operator vibe-codes a review-scraper dashboard, an Amazon aggregator spins up an internal tool to reconcile FBA reimbursements. Tools like Cursor, Claude Code and Lovable have made this cheap and fast — and they’ve made it easy to ship authentication holes and exposed API keys straight into production. Epherem is a free source-code security scanner built explicitly for that crowd, and while it’s aimed at indie AI builders rather than sellers, the underlying problem is one every operator with a custom app now owns. That’s why I read the launch thread closely.
What Epherem actually solves — and who it’s really for
The maker, Kirtik, frames the origin story plainly: while preparing to launch a student-and-SME marketplace, he started poking at the security posture of AI-built applications and didn’t like what he found. Existing security scanners, in his telling, were built for experienced developers — he could run them, but couldn’t interpret the output or act on it. The simpler alternatives mostly scanned live URLs rather than source code, which means they miss anything sitting in a repository. Epherem is his answer: a free source code scanner for apps built with AI, released after four months of work.
Mechanically, it does four things. You connect a GitHub repo or upload a ZIP. It checks for common security issues, exposed secrets, and vulnerable dependencies. It returns explanations, suggested fixes, and — this is the interesting part — prompts you can hand to Claude Code, Lovable or Cursor. And it shows you what the scanner couldn’t check, with an exportable report.
That last feature is the one the comment thread kept circling back to, and rightly so. Oleksii Sekundant, maker of SonOf, noted that keeping unverified checks in the exported report matters because the fix prompt and the scan’s limits should travel together back to the coding agent. Kirtik conceded a real gap in response: the full Markdown, PDF and JSON reports carry those limitations, but the individual “Copy fix prompt” button doesn’t — and he committed to fixing that. Raj Nagulapalle of FetchSandbox made the same point from the other direction, praising the decision to attach caveats to the fix prompt rather than shipping clean-looking fix text that people blindly paste into production.
Why this matters more to Amazon and Shopify operators than they think
Here’s the uncomfortable math. If you run a storefront on Shopify plus a handful of marketplace channels, your customer data — names, addresses, order histories, sometimes payment tokens — sits in systems you assembled yourself. The moment you bolt on a custom app, a middleware service, or an AI-generated admin dashboard, you’ve inherited a security surface that no platform’s compliance team is auditing for you. Amazon’s Seller Central will happily suspend an account over a data-handling incident, and GDPR exposure in the EU doesn’t care that your code was written by a language model in an afternoon. A free scanner that runs before you deploy is not a nice-to-have; it’s the cheapest insurance line in your stack.
How it differs from the incumbents
The obvious comparison set is Snyk, GitHub’s native code scanning, SonarQube, and the URL-first crowd like Detectify or Intruder. Each occupies a different slot, and Epherem’s positioning is narrower than all of them.
Snyk and GitHub code scanning are developer-grade: deep dependency graphs, CI/CD integration, policy engines, seat-based pricing that assumes you have a security engineer to interpret alerts. SonarQube is similar but heavier — it wants to live in your pipeline and your build process. The URL-first scanners are the opposite: zero setup, but they only see what’s publicly reachable, which means they’ll never flag a hardcoded Stripe key in a private repo or a Supabase row-level-security misconfiguration.
Epherem sits in the gap: source-code-aware like the developer tools, but explanation-first and AI-prompt-oriented like nothing in that category. The differentiator isn’t detection depth — I’d bet Snyk finds more — it’s the output format. Findings come with a suggested fix and a prompt you can paste into Cursor, which collapses the loop from “alert” to “patched” for someone who isn’t a security professional. For a cross-border operator who codes by prompting, that’s the whole ballgame.
Where the math breaks
The pricing story is deliberately unfinished. Kirtik says he initially planned to charge but made it free during early access — no pricing tier, no seat model, no usage cap disclosed. That’s fine for a launch, but it means you cannot model Epherem into a procurement decision yet. Free-during-beta tools have a habit of either dying quietly or arriving with a pricing page that surprises you. If you’re going to build a dependency on it, build it as a pre-deploy habit, not as a compliance control.
The second gap is scope. Epherem is not a substitute for a professional security audit — Kirtik says so himself, and the comment thread treats it as a starting point rather than a finish line. It scans code. It does not scan your live infrastructure, your cloud IAM policies, your CDN configuration, or your third-party integrations. If your breach vector is a misconfigured S3 bucket or an over-permissioned Shopify app, this tool won’t save you.
The infrastructure detail worth stealing
Buried in the maker’s technical comment is something operators running their own services should read twice. Epherem’s backend is a single Node.js/TypeScript service on Google Cloud Run in the asia-southeast1 region. When you upload a ZIP or connect a repo, the code goes to a short-lived Cloud Storage bucket, gets unpacked into in-memory disk — never permanent storage — gets scanned, and is deleted the moment the scan finishes. Only the report survives. Each instance handles one scan at a time, so one user’s code never sits alongside another’s. Cloud Run keeps one instance warm to dodge cold starts, scales to 30 instances under load, and Cloud Scheduler pings the same service every five minutes for cleanup and retries, plus once daily for an internal summary email.
That’s a masterclass in cheap, isolated, ephemeral compute — and it’s directly relevant if you’re running any internal tooling that touches customer PII. The pattern (short-lived bucket, in-memory processing, delete-on-completion, one-tenant-per-instance) is exactly what a returns portal or a review-management dashboard handling buyer data should look like. Most sellers’ custom apps hold data in a persistent database forever because nobody thought about retention. Epherem’s architecture is a reminder that “we don’t store it” is a feature you can actually ship.
What cross-border sellers can borrow from this
Three transferable lessons, in order of how fast you can act on them.
First, treat AI-generated code as untrusted code. The whole premise of Epherem — that AI-built apps have predictable, repeated security failure modes around authentication and databases — matches what I see in the wild. Kareem Ben of Mailwarm put it well in the thread: it’s handy that Epherem scans AI-built apps for login and database flaws, because those are exactly the things people miss when shipping fast. If you’ve shipped a custom app in the last year, assume your auth logic and your database access rules are the weak points, and scan before you scale.
Second, keep your limitations attached to your fixes. The thread’s best exchange wasn’t about security at all — it was about context propagation. When Epherem hands you a fix, it hands you the caveats too. That’s a workflow principle worth importing into your own operations: when you hand a task to a freelancer, an agency, or an AI agent, attach the “what I couldn’t verify” alongside the “what I want.” It’s the difference between a patch and a regression.
Third, isolate and forget. The ephemeral-compute architecture is the template for any custom service you run that touches buyer data. Upload, process, delete, report. No permanent storage, no cross-tenant contamination, no retention liability. You don’t need Cloud Run specifically — the pattern ports to any serverless platform — but you do need to stop treating “we’ll clean it up later” as a data-retention policy.
Where my judgment says it falls short
I like the product’s thesis more than its current execution, and I’d say that to the maker’s face.
The detection depth is unproven. Nothing in the launch thread establishes how Epherem’s checks compare to Snyk’s or GitHub’s on the same codebase — no benchmark, no false-positive rate, no list of covered vulnerability classes beyond “common security issues, exposed secrets and vulnerable dependencies.” For a free early-access tool, that’s acceptable. For a tool you’d gate a production deploy on, it isn’t yet.
The “AI prompt” output is both the killer feature and the biggest risk. Handing a fix prompt to Cursor is fast, but it’s also how you get a confident-looking patch that closes one hole and opens another. The maker clearly understands this — hence the emphasis on carrying limitations — but the tool’s own design nudges users toward the paste-and-pray loop. The individual “Copy fix prompt” button, as Kirtik admitted, currently drops the caveats. Until that’s fixed, the fastest path through the product is also the least safe one.
And the business model is a question mark. Free during early access, no disclosed pricing, a maker openly asking for feedback and user interviews. That’s a healthy launch posture and a fragile dependency. If your security workflow matters, don’t let it live entirely inside a beta.
Why Amazon sellers should care more than Shopify ones
Shopify merchants live inside a reasonably hardened platform; their custom code usually sits at the edges. Amazon sellers are different. Between Seller Central integrations, third-party repricing tools, ad-automation scripts, and the growing pile of homegrown dashboards pulling from SP-API, the average seven-figure Amazon operation is running more unvetted code than it realizes — often written by whoever was cheapest on Upwork. Amazon’s own data-handling rules are unforgiving, and a leaked API credential can mean a hijacked ad account or worse. If you’re an FBA brand owner with any custom tooling, you’re the ideal Epherem user even though the product wasn’t built with you in mind.
What I’d watch / test next
This week, do three things. Run Epherem against one custom app you’ve shipped in the last twelve months — pick the one that touches customer data, and pay attention to the “couldn’t check” section as much as the findings. Then take one finding and deliberately test the fix-prompt workflow: paste it into your coding agent, apply the patch, and see whether the caveats survived the round trip. If they didn’t, you’ve found the same gap the commenters did, and you should treat every single-finding copy as incomplete until the maker ships the fix. Finally, audit your own data retention: if any internal tool is storing buyer PII “just in case,” write down why, and if you can’t, delete it. The Epherem architecture — ephemeral, isolated, deleted on completion — is the standard your own tooling should be measured against. Watch whether pricing gets disclosed and whether a benchmark against Snyk or GitHub code scanning ever appears; those two signals will tell you whether this becomes infrastructure or stays a launch-week curiosity.
