Northflank Breached
status.northflank.com
status.northflank.com
This is a full infosec emergency unfolding here. No matter how grinding it is to motivate a team to invest in protection or resilience (and it is grinding): We gotta get ready. Stat! The AI-accelerated attacker apocalypse has begun. It's boom, boom, boom, thanks for everything, on to the next. They have us sighted and are firing for effect.
So credential rotation, tripwire secrets, DFIR on standby, solid vulnerability and intrusion detection, real listening to that signal, minimized blast radius, spending caps and time limits and tight scoping on credentials, fast incident alerting... We need to get on a real war footing here.
Yes?
Can’t say I’ve seen this?
"as if"
They're quite famous for being lax in security - mostly because they're a massive corporation, but also because they're high profile
But keep in mind Google got hacked by the Chinese in 2009 or so.
A problem is some people and teams are world class at a big company... But not everyone, everywhere. For a fun time, read about the rollout and internals of Azure.
> It is conceivable that, with a little poking, an attacker could obtain data, including secrets such as certificates, belonging to other tenants on the node.
> Moreover, the code was leaking cached entries and even entire caches due to misunderstood memory ownership rules, and suffered from a large number of crashes, in the order of 300,000 to 500,000 crashes per month for the WireServer web server alone across the fleet.
Last I checked major companies are still outsourcing essential engineering to save a buck.
A bit old, but how was this practice ever acceptable.
https://www.propublica.org/article/defense-department-pentag...
A multi trillion dollar company( Microsoft) too cheap to hire onshore for DoD contracts.
Period.
Your reaction is valid.
Believe it or not, Microsoft is more dependent on those government contracts than the other way around.
But that's a fantasy.
No one will face any consequences whatsoever. Retraining staff and migrating to a new cloud provider is very expensive.
Personally I think Gov should run its own cloud , as in from the data center level up. Don't depend on consultants, actually hire full time federal employees to do this.
Won't ever happen though. No way to grease palms without contractors in the mix
Digital Escorts
There's quite a history of US federal programs encouraging critical federal systems to operate within private infrastructure. This once required very strict scrutiny, joint DoD/DHS/GSA reviews, and was generally a long/expensive process that created the perception that a few providers had a gotten a hold over various agencies through these outsourced operations, which, combined with a fresh "interest" in federal efficiency, influenced a recent national defense budget authorization to formalize a slew of processes with a few minor tweaks as the law of the land, with a tweak or two to allow new cloud operators and service providers to authorize quickly and operate efficiently, particularly for low-risk classes.
Today, this means SASS providers must find an engineer with clearance (not just authorization to work in the USA). This cleared programmer documents and authors a whole host of (typically new) procedures, such as authenticating against a "federal enclave" authorization directory, delivering changes authored upstream to a government-controlled CI/CD system, and working with the SASS provider and the Government Services Agency (GSA) to ensure the backend operates when running within something that could be compared to a special AWS AZ. Things change upstream, and our operator prepares a 'significant change' request, which is, if important, gated by a liaison from the GSA. No one is responsible for scrutinizing implementation details of these 'significant change' requests, nor are their authors required to provide any information about themselves or the code's provenance. Given that hundreds of programmers may have written code included in said change (which is typically already deployed upstream), this is often efficient and generally fine.
Generally.
Step 2. Copy it into your repo. Who cares what the license says, how would the authors of that code ever see it being misused, because the place it is being misused requires a security clearance?
Step 3. Deliver the code as yours.
Truly, how will the people who authored something on GitHub ever know? Any circumstance you describe would require someone without clearance to know implementation details of some software. Which is to say, either the thing I describe happens all the time, or security clearances are overblown.
But they weren’t and probably aren’t and won’t be. They just put forth an image as much as needed to sell.
We love to talk rubbish about finance bros but that industry has had independent auditing as part of its DNA for a century[1]
[1]: https://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act
Far from only such company but the pass apple gets probably the biggest globally, its so emotional and thus I cannot take it seriously.
Still waiting for that glorious day.
Another possibility is advertising shadow profiles are able to correlate logged in accounts across YouTube and other properties.
Also, if vulnerabilities are so easy to find, it should also be easy to detect them through a simple red team exercise.
Defense is the only way.
You don't realize it, I imagine, but you're essentially advocating for the contemporary equivalent of requiring a license to print text on paper and distribute it.
Digital intelligence seems much less controllable. Near frontier weights are already out there, you don't necessarily need massive datacenters if you're not trying to serve commercially. Even if we we're somehow able to control what OTHER nations do through either treaties or threats of sanctions/force, working on this stuff is easily in range of many of the larger criminal orgs. Beyond all of that, there's always the chance that weights from authorized providers find their way "out the back door".
We've seen with crypto and darknet markets that even if you can fight this kind of stuff and catch bad actors, the most actual change you're going to effect is a temporary slowdown and the next guy who tries is going to be that much better. I don't doubt that regulation is going to be the initial route this goes, mostly due to the financial interests of the frontier companies and the desire to keep this build-out solvent for as long as possible rather than any true concern for actual safety and sanity. What's really going to need to happen though, in my very insignificant opinion of course, is we are going to have to change from the ground up how our digital infrastructure is built.
Maybe with the coming changes that is for the best too, our current systems are designed for people and I don't know the current numbers but it seems like agent traffic is already the bigger percentage. We may not be able to build our infrastructure on top of these large mountains of human designed legacy code. Maybe we need to be thinking about new kernels, new servers, new protocols and stacks.
We seem to be very quickly reaching a point where is something is not mathematically provable to be secure then it is not secure at all.
Trying to protect ourselves by putting restrictions on the technology would be like trying to hide from a tiger by wrapping a towel around our heads on the basis that if we can't see it then it can't see us. That trick only works on imaginary monsters, not real ones.
I've seen attackers install claude code on compromised servers
In my career I've seen maybe two companies have pretty good protections. Both had government contracts so they had no choice. Otherwise there's no reason for companies to secure their stack. They make money easier without it.
The buildings are on fire because they're being built out of straw because it's cheaper. Only a government regulation to build out of brick is going to stop the fires.
The usage of shape here triggers me.
There's no amount of "nicer to use" that can replace security, at least certainly when selling to enterprises
So, you can always say: Look, it’s not us (especially not my org!). It f’ing Microsoft/AWS! Everyone got hacked.
You and your career are gonna be just fine.
But it you actually NEED security, it's clearly not an option.
It is trade-off between risk and access/productivity with a cost dimension always.
Depending on your threat model you could go to typewriters /paper as some Russian department did famously few years back too.
The real sensitive customers are on oxide.
If you want deniability no one should be doing business with you.
Turns out, when a major provider went down all of our users were too busy fighting their own fires. When they do notice, it's on a day when ALL of their vendors are struggling so we don't get singled out as a bad apple.
Literally 0 of your customers will notice that you are down if their own systems are also not working.
This is perfectly valid for many businesses, up to a (shockingly high) level.
If none of your customers are up to call your service, it does not matter if your service is up or down.
Let us look on the front page and see if there are any, oh look here is one: https://www.binarysecurity.no/posts/2026/10/one-root-case
My bridge that collapses is adequate and acceptable because other people make even worse bridges that collapse even easier? No, the bridge still collapses, everybody gets a F.
I’m not even blaming Zuck for that, he didn’t really invent it, though he certainly popularized it — he just made an astute observation of the dynamics in software and turned it into a company motto.
As is what constitutes the standard of “adequate.” Which BTW is the standard in ALL engineering (not just security or software) because we live in a world where economic pressures apply and costs must be managed. Trivial example: bridges only use an “adequate” amount of steel and concrete because they are not free. The word “adequate” fundamentally involves the concept of tolerances. There’s a reason we consider over-engineering a bad thing.
So which development approach would you say is better correlated with good security outcomes?
Another way to look at it is, bureaucracy is an aspect of the corporate culture, and lasting security comes down to having the right culture. At least in that respect Microsoft is doing something right. Doubtlessly a lot of that bureaucracy is ineffective, but it's a signal that the cultural intention exists.
As a relevant counterexample, we've never heard of these kind of processes at Meta and so you get Cambridge Analytica.
My perspective is skewed by my experience being on a security-adjacent platform team for years. Our biggest challenge was not external threats, it was internal teams seeing us as friction on their productivity, to the extent that it regularly led to escalations.
So when Cambridge Analytica happened, I played it up for all it's worth; Meta may move fast because they didn't have our "bureuacratic team", but look where it got them! Unfortunately the $25B penalty happened just last week... I'd have gotten infinite political mileage out of that.
thats the crux; are you working for the paycheck, or for the truth?
could be both, but pretty much all "i was right" stories start with "everyone else said i was wrong"
when i look for truth, if i dont find it myself through work, most people eager to hand it out had self-serving interests
security is proven through resilience? maybe. i guess i'd set up a box and try attacking it myself to know its secure. until someone else comes along and trips over it :)
Of all the conspiracy theories you have heard of, or can conceive of, anyone who comes to believe one would say that - and almost all of those people would be wrong. Same for almost any fringe idea, almost any revolutionary discovery or invention, medical cure, chemical transformation.
Broadly I think you're much more likely to be the victim of a platform-level breach involving an immature startup PaaS than a hyperscaler cloud, however I think for small teams the alternate risk you take on is that AWS/GCP/Azure are full of landmines and extremely easy to misconfigure in insecure ways if you don't know what you're doing. Especially if you have AI telling you confidently wrong things.
But they are also very highly incentivized to be more secure. They have millions of customers (hence a correspondingly higher expectation of trust) and billions in revenue from the trillions in economic activity happening on those platforms (hence a correspondingly larger target on their backs.) This means exponentially higher liabilities. And that probably matters more than any other factor.
They will still make mistakes but they have the resources to make them less.
I doubt that such intense level of thorough testing can occur in a smaller company.
I still love small VPS providers and use them myself but it is worth knowing why enterprise is willing to pay a premium over those to these hyperscalers (it is a trust premium)
You can get close if you have either:
1. the ability to spend hundreds of millions on security operations yourself
or 2. the ability to airgap the systems you are securing
Azure would beg to differ.
So when I look throughout my long employment career for best security and organizational practices, all the highlights are still relatively, relatively undersized companies, with headcounts in the 3-4 figures. It's as they grow, and start to be multi-headed behemoths, that they decay again, as what is good for the responsable mid-level exec, for the business unit, and for the company as a whole start to have nothing to do with each other. That's when you can smell the decay in the hallways. A few large companies manage to stave off this rot a little more than others, but it's inevitable. Then nothing important can be done in a timely fashion.
I wish that was the case, but that isn't how startups fail generally, sure very bad user facing breaches could cause something like that, but lots of platforms with too much jank have somehow survived all of these cyber vulnerabilities before, and will probably keep at it.
For a majority startups it's about connections and relationships rather than competence. Very few even consider building actually useful products to be a priority after the initial work of building it.
and anyone else’s money I’m asked to spend…
Plenty of morons there
Are the people on my Azure team smart? Probably. Are they incentivized to actually help me solve a problem? No. They’re obviously incentivized to increased my license spend.
We can lower our standards instead
https://www.broadcom.com/company/news/articles/cloud/as-ai-w...
---
Half of all enterprises, 50%, have already repatriated workloads from public cloud to private environments, up from 35% in 2025. The breadth of what they are bringing back, and the reasons behind it, have both increased considerably.
Workloads with high security or compliance requirements remain the top category at 51%, unchanged year over year. But the categories moving up fastest tell a broader story. Business-critical workloads surged from 36% to 47%, an 11-point jump. AI or generative AI workloads, which were barely on the repatriation radar in 2025, are now being repatriated or considered by 43% of enterprises.
---
https://unitedlayer.com/cloud-repatriation-private-hybrid-cl...
Noted that GEICO cut $600mil in cloud spend.
If you think governments (US and China) are going to tolerate people using models for anti-social behavior, I have a datacenter to sell you.
SOTA open models need tens of thousands of dollars worth of hardware to run.
I get your analogy, and it feels right, but the compute requirements to run these models are extreme. That analogy falls apart when it necessitates having a corporate 3rd party run the models for you. They will not tolerate breaking laws.
If China says no more, then the best the masses are gonna get on their high-end setups are the 30B class models. Which are decent, but not "hack my bank", errr, "protect our bank" decent.
Piracy flourished because you only need an operating laptop to participate. LLMs you need a server rack of GPUs to participate.
I'd also wonder about what you can get done with a smart model running very slowly. You can run the biggest open weights models on relatively mundane hardware if you don't mind measuring your speed in seconds per token. That's going to be untenable for interactive use, but might be fine for "go hack this thing for me" if you're patient.
It's time to leave GCP, AWS, and the rest.
Google and Amazon markup can eat it. Fuck those guys.
Let's not forget that Google and Amazon tried to offshore us, played a role in inventing the labor-displacing models in the first place, and that don't give a shit about any of us.
I hope they ossify and turn into the next IBMs.
They thought AI would lead to growth and a greater concentration of wealth for themselves, but it's actually the seeds of their own destruction and dismantlement.
Supposedly Apple holds the encryption keys on their own infra, but I still found it interesting how they are just reselling Google Cloud storage here.
It will take a few bankruptcies until security is taken seriously.
You can't defend yourself from everything, but you can try to make you life easier by reducing the attack surface and make side movements more difficult.
You see this already with uptime. If Github or AWS has a major outage, it's in the news and even people that don't understand software realize it's just "something happening today, everything is down".
And, unfortunately, in practice customers don't care about this inverse, when "everyone else is down but not that one product".
This has happened to many high-profile self-hosted pieces of software just this past month.
Or do you mean a customer was running it?
> But then, you're unlikely to be the top target of anything.
That would have protected you 3 years ago when a human had to bother to attack you. Today it doesn't protect you because it's trivial to deploy an LLM to act like an APT against any random target that shows up in shodan.
It takes more effort to secure on-prem software today than it did just a couple of years ago. Updates are more frequent, zero days are more frequent, attacks are more common, more persistent, and more automated.
I think most people responsible for securing production systems today will share the experience that their workload has increased.
And I am literally a security engineer; the work has absolutely not gotten harder, it's just changing in how you think about security, just like it shifted before from "secure the perimeter" to "defense-in-depth", it's now changing again to focus on automated response and compartmentalization/ segmentation (and I mean real segmentation, not the checklist-style "we have 3 vlans, but they can all talk to each other" 'segmentation' you used to see.
Yes, everyone is rushing to implement zero-trust principles for real now. It's getting harder to trust that your public facing endpoints don't have vulnerabilities, and it's getting harder to trust that your internal software and endpoints haven't been compromised from within your pre-existing trust boundaries. A lot of the increased workload is due to patching up the existing security infrastructure, and on top of that, building out new solutions to better fit today's threat landscape.
For stuff like Netflix that is truly consumer-facing, where mTLS or IP whitelisting are non-starters, the reality is you have to rethink your model entirely.
Also, I'm not sure where you got the idea I'm talking about on-prem only; this also applies to using IaaS/ cloud hosted infra.
If you're a security engineer responsible for securing only:
1. a public website
2. stuff that can be ip whitelisted and/or use mTLS
Consider yourself very lucky. Most orgs need to expose a lot more than that.
> Most orgs need to expose a lot more than that.
No, in fact there are only 2 kinds of connections:
1) public, necessarily allows anonymous/unauthenticated connections
2) non-public, doesn't need to allow unauthenticated connections
Name a service, and I can tell you which one it is.
Or put another way, there are authenticated and unauthenticated services. If you can authenticate someone at the application level, you could do it at the network level.
Most places have combined them at some boundary, for ease of access, but there is no case in which an authenticated application endpoint (even /login) has to allow unauthenticated network access to it.
And in all seriousness, name a service that is not a public website, but cannot use mTLS or IP allowlisting.
SFDC? mTLS. Customer webhooks? IP whitelisting. Data warehouse? PtP VPN.
They do it all the time, piecemeal, that's part of what anything-as-a-service delivers. If you don't want to secure an app, buy a SaaS one. Don't want to secure infrastructure?, buy an IaaS.
> Most places have combined them at some boundary, for ease of access, but there is no case in which an authenticated application endpoint (even /login) has to allow unauthenticated network access to it.
> And in all seriousness, name a service that is not a public website, but cannot use mTLS or IP allowlisting.
Literally any SaaS software where the customer does not or cannot practically install a certificate for you or provide a list of IPs in advance? mTLS is almost never used in a browser unless you are connecting to a government website with a pre-shared smartcard. IP whitelisting is great if the end users only work from behind a VPN or in an office. But there's a whole big world of people who cannot or will not do that.
There are already plenty of methods that are low-impact to users, like certificate-pinning in apps, and all you have to do to make it per-user is roll in their user-specific key JIT when they download the app.
Users will not be happy (just as no one is happy Reddit is going app-only), but they will do it, especially when it becomes common as companies decide they don't want to be the 5th breach notification on HN in a given day.
Today we have Bun, Cursor, Northflank, and now Linode!
2) that's not what "rolling your own" means. Building your own web proxy is "rolling your own". Standing up e.g. Caddy and configuring it is not.
> I think people will move back to their own hardware
> self-hosted pieces of software
2. arguably -- but lets set aside what you think the word means and respond to the obvious meaning of the comment you're replying to.
The point is -- doing shit yourself makes it your problem to do correctly and requires sufficient resource allocation
2. I still don't see where you got that they are only talking about configurations versus messing up an implementation (I.e. in a paramater they coded incorrectly)...
But that aside, even on AWS you're still configuring your proxies, gateways, load balancers, etc. AWS gives you just as much rope to hang yourself with as a box in a colo network cage does. Companies are already doing this stuff themselves, on-prem is not more security work. IaaS is about scaling and maintenance load, not security being handled for you.
For Entreprise, the shift will be towards hyperscalers as they want trust and less blame (Nobody got fired for picking AWS)
For consumers, we care about pricing and stability and control and we will move back to our own hardware or cheap VPS providers and self-host things.
The middle ground would be where the slight pain could be at in my opinion.
That's not how consumers work. That's a nerd/geek/hobbyist mentality.
If Ikea and Wayfair went out of business you wouldn't expect consumers too take up woodworking and build their own furniture en masse.
Mass credential stealing is just the top funnel of hacking and (compatativly) isnt that lucrative - these credentials are then sold on the black markets to the next step of hackers who use them to exploit targets.
With unpatched systems and self hosting, this second group can just set an llm at a target and have a much higher chance of success without needing credentials
It would be a dream for the infiltration hackers to have everyone self host. Unpatched and miscondigured systems would be everywhere and LLM automation could make mass scanning them and exploiting them very attractive - not mass scanning and exploiting them for credentials stealing, no! For layer 2 stuff
Being a small target is not helpful these days, attacks on on-prem software today simply scans the internet, or uses databases by people who have already scanned it, and is automated.
On-prem software has not been spared from the recent spat of security incidents.
This is exactly the problem that LLM assisted attacks solve. For a human attacker, the extra work to figure out a bespoke solution is too time consuming to be worth the effort. LLMs can search for vulnerabilities and spit out bespoke attacks like it's nothing. On top of this the bespoke solutions weakness leans heavily into the AI attackers advantage: response time. Even if they can just get your company's single Anthropic key, if they do it at 2am while your one infra person is on vacation, they have plenty of time to extract enough value for their effort.
I agree with the move to hyperscalers. The future (well, actually present) is going to be constantly seeing new attacks happening. The only real solution to this going to be having teams of people and agents constantly watching for these and able to deploy fixes and respond to risks immediately.
I had a html game I built for my niece on railway with an open ai API key so she could vibe code changes. No hacker would have looked for it but now I am catching strays because railway was a juicy target. Hyper scalers would be the same. Some random colo not so much.
This is depending on the cost of tokens not trending towards zero. Maybe not today, but in a couple of years I'd expect hacking models on asics to reduce this to almost nothing and the systems being very competent in using deterministic tools very well.
Yes, LLMs can easily knock over your on-prem docker appliances.
But you can still put stuff out of reach. I'm currently designing a key on-prem appliance that is can be compiled down to transistors, giving deterministic wire-speed performance while ruling out RCEs. It's cryptographically homomorphic: it processes authorized inputs but doesn't know what they mean, so an attacker who obtains the disk doesn't benefit either. The design will be highly resistant to exploits, and is likely to remain outside the "next-token" prediction training set.
This is the kind of thing AWS won't sit down and engineer for you. But thanks to LLMs I finally have the time.
the problem is owning hardware is hard
I wanted to write a blog post about it as I was thinking the same but I guess a comment will help me get my thoughts across just as much.
Either we are gonna see a convergence to hyperscalers as you mention, or we would go back to completely indie companies which compete on perf/price.
There could still be some value to "nicer to use" certainly but with AI, we are gonna see almost every product as being "good-enough" if I am able to convey my sentiment.
An anecdote is: Proton's an middle-ground company. I am seeing the Verge article which states that their CEO has gone a little crazy over the use of AI and the wording makes me lose trust within it. Proton's whole point is security and yet it's having this, It has some stocks in non profit and is a swiss company. It shouldn't have been this way and would've been one of my least anticipated companies but I guess they want growth at all costs and the growth has been slightly lesser than expected and now they are burning the good-will in many ways.
I have to wonder that even if proton might have good engineers, then within this pressure by their CEO/CTO. I cannot trust the engineering talent because of these issues because they are very much forced by their company to use AI.
Proton is also really expensive.
Now just today, also, with a company so big as binance getting hacked and losing 6.5 Billion$. My trust within security just because its a large company is less.
On the other hand, I know a guy called Vikas on lowendtalk who operates his own mail platform called mailbig. I know he vibe-coded the landing page and might've vibe-coded something but it is really cheap. I also know francisco whom I have talked to who runs namecrane. (I think mailbig uses namecrane in many ways)
Perhaps E-mail can be a sensitive matter because you have to place trust in the provider even more because the protocol is not really that much secure but suppose it's an matrix instance (where it is genuinely encrypted) then that shifts it even further. I do trust NameCrane and NameBig from what I can gather.
I'd much rather support them and their cheaper deals than some other middle-corp. Sure some security factor can come in but also, the difference feels comparatively less and the balance has been made
The market will slightly squeeze as Hyperscalers will introduce the solutions of the middle-ground and the new players will everyday enter into the field with more competitive pricing just as well.
So in short, Enterprise will move towards the hyperscalers. Generic Consumers will move towards the cheapest option. The moat of the middle ground where UI/UX was the differentiator is being turned down. There would be some mix and match and there will be cost-savings for Enterprise to move from hyperscalers but it would depend on a lot of factors.
“malicious actor had access to abliterated models and substantial compute resources which enabled them to perform highly sophisticated exploits against our infrastructure.”
They don’t provide any details but pass it off as an advanced AI attack. I’m going to just read that as what it is. A likely scapegoat for shitty security.
that way if the provider gets popped, they need my binary to decrypt it
it shouldn't be necessary and it sounds stupid, but in cases like this, it proves invaluable (it appears they don't have customer code/binary access, but maybe that wasn't important enough to mention)
I rushed to the Claude platform console and was expecting to see a 4 figure usage bill or something. Luckily there was no usage.
But imagine if I were traveling. Even a rot13 of the key would've bought me enough time to rotate.
2 lessons:
- don't name your env var "CLAUDE_API_KEY". Call it "ARG_1" or something
- at least do some obscurin' so that the value doesn't start with "sk-ant..."
I think siblings are correct that the more widespread this is, the less effective once every dump is run through a "also look for keys in the binary" step.
That way read access to your infra provider is not sufficient, it requires an active component.
so you dont need env2 to decrypt env1.
https://seal.zone/ does this
Presumably it means much more behavioral security and inherent friction built in to everything we do. Maybe high value transactions will just inherently have to take multiple days to do, just to slow down things enough that human reaction time can equal what LLMs can execute?
On the technical side, I can see zero trust becoming completely saturated through every layer. The passkey you authenticate with isn't opening a gate to a trusted tier within which components trust each other - even within the same software component. Every internal function call at every layer doing hardware signature verification against continuously minted private keys (since we assume exposure, the lifetime can't be longer than milliseconds now).
It's really interesting to think through what a fundamentally robust security environent does look like if you bake in an assumption that technical security is impossible.
One reason: There is zero reason to suggest security is possible.
if AI tools get good enough that they can exploit ingrained hardware properties such as subtle timing and race conditions and swarms off them become cheap enough to deploy so that they can persistently exploit low probability events we could reach a state where I think it's actually practically impossible.
Ironic, after decades of defrictioning.
Otherwise, I think this is a issue of vendors, even if potentially most vendors fit into the basket of having insufficiently good cyber posture in AI-era.
"Product Hunt has also said the quiet part out loud."
?
> Run agents and everything they build.
Oh, it’s 100% Claude-slop. How shocking they got hacked! /s
(or things will stay messy because people will throw AI at the problems instead of hiring real security professionals)
The sky isn't falling.
It’s the death of homegrown software.
1. Good engineers should have had a firewall/waf/nat/thingy infront of their linux systems, and alerting at least on those directly exposed to reduce/eliminate blast radius
2. Good engineers don't enable MTCP (which as far as I can tell is largely a desktop feature) on firewalls
3. ???
4. Profit!Combined with defense in depth across the perimeter. Come on yall, we've only had these tools at a high level for maybe a year and we have already forgotten the basics?
Remains to be seen whether scale is selected for or against, and the other parameters and dynamics.
i.e. https://en.wikipedia.org/wiki/Cretaceous%E2%80%93Paleogene_e...
... in fantasy land.
How do you even want to calculate costs. Should you be even calculating costs when real damage is also a lot of misery, some heart attacks and 50k people lose 1 year of their life due to massive stress for example.
Well, at least they were honest I suppose
If anything, AI makes running linux boxes much easier than 4 years ago; it's now faster and the learning cliff is gone to get the correct CLI commands and digging into system logs.
As you build something bigger and bigger, quickly, with several people building, guarding all the doors becomes exceptionally difficult without a kind of aggressive discipline which is contrary to the "go fast" culture.
Cybersecurity in practice until now, for most companies, has been an insurance problem, not a quality problem.
Such companies are quickly discovering that insurance is a post-hoc partial correction and not a proper solution.
This situation will not improve anytime soon for most companies.
The solution does not require any new magical tools.
And sure, you can encrypt at rest, and perhaps even enforce that only re-encrypted versions are ever seen by the management/API web server. But fundamentally this display requirement means that if your management/API web server is compromised, users' secrets can be obtained by a process of impersonation.
As costs and broader economic impact and perhaps even injuries/deaths related to software breaches continue to grow, there will be growing intolerace for vulnerable software, just as there was intolerance for collapsing bridges and buildings.
And I'd also at some point expect something like a "building code" that applies to software that will be exposed to the public.
What are your opinion on the concept? Growing trend that should be encouraged or a mistake for most startups? Would you choose one provider over the other because of it assuming price was about the same?
I get that this is often a super expensive "call us" option today, but in theory it doesn't have to be, so for the sake of discussion let's assume it can be delivered at a reasonable cost for the provider at reasonable price for the customer.
If people from Northflanks is reading this, I'm sorry for the incident and I hope you recover as soon as possible.
a hacker might know how to hack your service, but they'd have to find it first.
I was thinking of a fully private deployed within the customers cloud account connected to the software provider via Private Service Connect or PrivateLink and then either only available inside the customers private network or only via their own firewall. The point being that it's not publicly exposed.
Since all your metadata and env vars live on the control plane, any issues there could affect the BYOC cluster.
There are some other options for a separate control plane, e.g. now they seem to have the term "forward-deployed control plane" which might be fairly close to what you're thinking of, but their BYOC by itself does not get what you want.
Security is a perception, but right now it seems like it needs good PR.
Run agents and everything they build. Secure execution from the first sandbox
1. Ask them about what percentage of their own resources goes towards cybersecurity, audits etc. Would they even tell you.
2. Technical stack maturity. If the details are available, because they won't reveal any of it to you.
3. Other signals: Do they give talks on platform security, who is incharge of their cyber security.
Yes:
* you do ask about things like budget allocation, audits, and internal compliance processes.
* you do ask about the tech stack, how it is maintained, and what the patch and disclosure policies and SLOs are
No:
*you do not rely on what figureheads say publicly; none of that is binding in the way legal agreements are
And if you're a vendor, your deals desk probably has all of these answers packaged up and ready to go; or even published on a website like this https://spyglass.trustshare.com/home (no idea who that is, it's a random company's compliance portal I found while googling my employers compliance portal provider).
[edited for formatting]
Not in English majority speaking place at the moment so not surprised "runtime platform" for "autonomous software" is not immediately understood as the somewhat etymological contradiction that it is. Runtime doesn't even have a definition, really. but autonomous implies independent and not ran / hurried like bison off a cliff...
platform and software
Unfortunately I'm not longer using PaaS tools. Instead I use Azure for work and vps now for all my personal stuff. With AI it's easier than ever to lock a server down tight and mitigate this kind of exposure.
I'm actually pretty pissed at this now. I have a throwaway appstore app that uses northflank for the backend, now I have to go in and rotate revenuecat secrets, apple secrets, ai secrets. For an app with basically 2 users.
Can I even delete the app on apple's app store or whats the process like what a pain in the ass. I'm pretty done tbh.
Now, to be clear, abliteration was no state secret, but that blog post was pure accelerationism.
And no, before the labs there was a degree of fear for everyone to hack into some one else system. With the labs changing the narrative, anyone can just blame the agents for the breach, whoever did it would only get fame and no blame
What’s changing now is that models are getting more powerful.
The timing of all of this is much easier to pin to the creation and proliferation of capable of open weight models. Anthropic calling this out is not the cause for it; it's just an obvious correlation.