The problem with Mythos and Glasswing related hype is that finding vulnerabilities isn't the problem for most organizations. It's great that Mythos and similar models can find vulnerabilities that remained undetected (and hopefully unexploited) for years. That's valuable, especially in open source projects, but it's never been the real challenge for software companies.
The real problem is balancing the need to fix vulnerabilities with the mandate of shipping new products and features. At every organization I've worked for or with, this has been the natural friction point. That's good: Product should make customers happy, and Security should keep the customers and their data safe.
Ultimately, the whole business should share these goals: everyone should strive for a resilient, useful product shipped quickly that delights customers. Easier said than done, but the friction should be tactical ("how do we spend engineering resources?") rather than strategic ("are security fixes important? do we care?").
Which is why I'm much more interested in automated (or semi-automated) PRs to actually fix discovered vulnerabilities rather than just identify them. But, as this project implies, it's not always that simple. It's easy to fix vulnerabilities if you don't care about breaking other functionality.
In my opinion, it's currently still necessary to have a human developer in the loop to make sure functionality in product is maintained, and potentially security in the loop to make sure the vulnerability is actually fixed and not just obfuscated.
Once this technology is sufficiently advanced -- and I think we're getting close -- my hope is that developer and security time will be spent thinking about resilient software design and architecture, not code-level vulnerabilities.
The Fallout games often exemplify this: nearly every decision you make is morally ambiguous, and often has far-reaching repercussions in the story and world.
IDK if i'd go that far... there's usually clear paragon and renegade pathways. I'd agree that they do include a few morally ambiguous quandaries, but they are not regularly encountered.
FNV is peak franchise, IMHO. Master's study of how to make a sandbox tell a narrative.
Also, and this is trivial tiddlywinkies, the designers bothered to do a little bit of light reading about how guns actually work. I am continually distracted by impossible mechanisms in later FO games.
The artwork on the store may have been an earlier (non-final) version, or there's just simply multiple variations, which is usually the case for the t-shirt art.
Job Snijders works closely with the artists each release, and runs the store.
Edit: oops, bad eyesight led my brain to believe "no way this is legible text" when in fact it is. Needed a screen magnifier to read it clearly. Though the other items have police in place of security.
My bad. I have poor eye sight and on my first look the fonts appeared jumbled. On second look with a screen magnifier I can see it reads security while the others read police.
It's easy to be cynical because, yes, both the problems and solutions seem dead obvious in hindsight. But for a long time (and maybe even still), a hacker creed was "move fast and break things."
It's great that there's so much momentum in fixing the glaring problems with supply chain systems like npm, but I'm concerned that we're entering a new era of security-related problems caused in large part by agentic development.
I'm not just talking about Mythos/Glasswing surfacing vulnerabilities in pretty much everything it touches; I think the way we're developing software, pulling in dependencies, and potentially losing human thought modeling of complex systems is going to lead to a lot of hacked together software and infrastructure that humans won't fully understand.
I hope in a few years we don't look back at today and wonder how we could have been so naive -- how we failed to actually plan for the long-tail of AI development in a way that doesn't solve problems by attempting to just use AI to rebuild complex systems.
He certainly popularized it (maybe coined it), but I've seen a lot of organizations and developers repeat that mantra.
Even without the specific words, look to product teams debating tradeoffs of going to market vs. waiting for better security controls. They're pushing for faster product release every time, at pretty much every org.
Hackers were moving fast and breaking things first. Faster than any corporation in fact. We didn't notice because their computers weren't powering anything useful. How do you think projects like GNU happened?
I stand corrected! My memory is pretty vague on this, but I was pretty sure Joel had said something very close to this in one of his blog posts in the early 2000's, but it looks like Zuckerberg was the first one to use the phrase "move fast and break things":
We don't need hindsight for the problems of supply chain security to be obvious. Security people were writing and doing talks about this stuff over 10 years ago, just (like most things in security) things start getting addressed once the pressure of incidents gets high enough :)
We'll see more of this, but this particular review is driven by marketing narrative. I'll explain what I mean:
Back in 2010, as a security engineer, I also looked at OpenEMR. It was an absolute disaster, and was (and is) somewhat well-known as such. I found and published vulnerabilities very similar to these sixteen years ago. This is not exactly the Fort Knox of software.
It makes sense for AISLE to demonstrate that they're able to find vulnerabilities here, but I'd love to see a side-by-side comparison of modern SAST and DAST reviews. I bet we'd find similar vulnerabilities.
I think the idea is that if you're given an improperly configured restricted shell/command access, you can use any of the listed tools to gain access to some subset of what that user would normally have access to in an unrestricted environment.
A very simple version of this would be if you set a user's default shell to "rbash" but the user can just run "bash" to get a real shell.
Specifically, the idea here is that companies like Anduril, Palantir, and SpaceX are rapidly delivering cutting-edge technology (including software) as opposed to the traditional defense contractor process of long, drawn out, super expensive projects mostly focused on hardware (such as building a new type of jet).
It makes sense: this is basically what happened in civilian tech, too. Delivering high-tech solutions quickly -- dare I say with agility -- is usually the superior approach.
Basically it's a return to the pre-1990s model of defense iteration - dual use components constantly iterated on by newer challengers in direct competition or partnership with larger players.
This is a model most countries are working on now - from China to France to Russia to Ukraine to India to South Korea to ...
Also, for all of HN's moaning, this has bipartisan support in both parties. Based on my network, NatSec and Defense Policy roles haven't seen significant turnover irrespective of admin and those of us in the space are aligned with America irrespective of who's in the White House.
It's the same way how at SF Climate Week right now where plenty of founders in the space are taking conversations with VCs irrespective of political opinions. Climate and GreenTech is dual use, and even a couple European trade commissions have been working on introducing their startups here and helping them expand IP and R&D headcount IN the US. Clearly the overlap between pissy HNer and people doing s#it doesn't overlap as much anymore.
It's used to threaten opponents that we can efficiently kill them while minizming our casualties. That's the point. And has always been the primary driver for most tech development.
You may hate it but you don't matter. We all do it no matter what.
A large portion of the commenters here only heard of Thiel because of Trump, and think the industry begins and ends with him. It does not.
> You may hate it but you don't matter. We all do it no matter what.
I've seen you say "you don't matter" in many of your comments. Why do you think like this? Sure, we don't matter much most of the time, but this kind of elitist thinking and decision-making is clearly leading to growing discontent, which can then be used against "people who matter". Perhaps the tools for controlling the masses are now powerful enough to make what you say true, but there's a chance your "let them eat cake" attitude will lead to the downfall of the people who currently matter.
If you check their profile you will see they are a VC. I’m sure they believe they are one of the masters of the universe, and by “you don’t matter” they mean other people, not themselves. They have money and power, so they get to matter.
> If it were secure, it would only notify that there is a message, with no details included.
You're right. This is configurable via settings, but is not the default state.
That said: if I can get friends and family to use Signal instead of iMessage, that gives me the opportunity to disable those notifications and experience more security benefits.
But I agree with your point: most people think that Signal is bulletproof out of the box, and it's clearly not.
Dang has changed the title and it seems that he may have had a minor error doing it . Must have been a typo from his side changing it and that's okay! I think that Dang will update it sooner than later.
It would be an interesting and potentially useful project to combine these camera locations with Maps routing -- similar to "avoid toll roads," we could "avoid surveillance cameras."
If you're in the US, stay away from Home Depot and Lowe's if you want to not be around them. It's not universal, but it's surprising how much they are often there.
I get it may have its application in theft recovery, but it also happens to have some strong potential for ICE raids for day laborers. I don't think it has much application to theft prevention as I doubt many people even know they are there.
The real problem is balancing the need to fix vulnerabilities with the mandate of shipping new products and features. At every organization I've worked for or with, this has been the natural friction point. That's good: Product should make customers happy, and Security should keep the customers and their data safe.
Ultimately, the whole business should share these goals: everyone should strive for a resilient, useful product shipped quickly that delights customers. Easier said than done, but the friction should be tactical ("how do we spend engineering resources?") rather than strategic ("are security fixes important? do we care?").
Which is why I'm much more interested in automated (or semi-automated) PRs to actually fix discovered vulnerabilities rather than just identify them. But, as this project implies, it's not always that simple. It's easy to fix vulnerabilities if you don't care about breaking other functionality.
In my opinion, it's currently still necessary to have a human developer in the loop to make sure functionality in product is maintained, and potentially security in the loop to make sure the vulnerability is actually fixed and not just obfuscated.
Once this technology is sufficiently advanced -- and I think we're getting close -- my hope is that developer and security time will be spent thinking about resilient software design and architecture, not code-level vulnerabilities.
We'll see where it goes.
reply