Corporate Secrets Were Left Exposed. This Guy Found Them All
wired.com
wired.com
>VirusTotal stores the analyses and report. This allows users to query for reports given an MD5, SHA1, SHA256 or URL and render them without having to resubmit the items (whether URLs or files) for scanning
AWS's response seems muddled. To make sure that "customer credentials [...] belong solely to customers" surely you would typically want an endpoint to revoke exposed secret keys?
But they should accept feedback about exposed secret keys through some way where a responsible person in company could act on it.
Could you elaborate? Many other services have automated revocation, either through scanning for exposed keys or offering an endpoint to submit keys to, and as far as I can tell the way it has played out is in successful warning of and prevention of many leaks. I don't see how lack of it can be justified as a "security" measure.
If you want to see something scary, look at the fake story Demirkapi managed to post, and note the domain name - actually nytimes.com! (IMPORTANT: The story is not real!)
https://web.archive.org/web/20230330043732/https://intl.prd....
Again, that's not real. But if the hacker tried, lots of people could react long before they realize it.
Recent research showed the increase in the number of programmers twofold every year all over the world.
That means 75% of Programmers (SW Developers) have less then 2 years of experience!We are still a very inexperienced and unregulated industry.
Theoretical computer science results get ignored for decades, until people like Carmack randomly sit down and read a book. (The rest of the world then gets to read about it years later in a biography, and it's still revolutionary since nobosy else sat down to read a book in the meantime.)
A lot of institutions know how to write efficient, safe software, but at best will talk about it in a blog post, their experience will never filter down into classes to teach the next generation.
And because that's not bad enough, we try to suffocate every possible problem with "more headcount", since that's easier than actually figuring out what your core problem is.
That's not to say the average programmer is a dunce. The opposite. It's simply that science and theorems are part of scientific discourse. They are usually not complete proofs and come with nuanced caveats and limitations.
It takes someone with scientific training and discipline to take that, and turn it into a feature for some IT product.
Not your average programmer. I don't think it's realistic at all to expect the IT industry at large to do these things.
That's what industry- and field- standards bodies used to do. They provided guidance and examples in that can be applied by the average programmer. These used to be sponsored by companies in their respective fields. But these days the focus is more on open source. Which has its own advantages and disadvantages.
But in the end you get what you pay for in this industry. Programming jobs pay pretty well of course, which is because there is both scarcity and a lot of demand for them. Experience is even more scarce and not all companies are willing to pay for it. But mostly the issue is really companies trying to do things on unrealistic budgets with people that aren't necessarily very good at what they do.
I'm actually turning 50 in a few months. I recently got to work with people that are actually older than me, which is very unusual for me. Usually I'm the oldest in the room and at this point old enough to be some people's daddy even. I worked with a few interns 30 years younger than me recently, for example.
Mostly I actually prefer working with young people over older people in my teams. More mental agility and less set in their ways. I actually hate that in myself when I catch myself. Mostly older doesn't necessarily mean wiser.
I disagree with the calls for regulation here btw. The issue is not with engineers but with their employers not willing to pay for them to do better. There are plenty of certifications, security reviews, etc. that you can pay for. The issue is companies not doing that, skipping it, or treating it as a box ticking exercise and generally not taking it seriously. This stuff doesn't necessarily lead to good engineering decisions. Most banks are a good example of lots of ass coverage in that form combined with lots of technical debt. They buy plausible deniability, not better engineering.
Wouldn't regulations compel the employers to pay for better quality? I thought that was the most common need for and benefit of regulations.
TL;DR a security researcher found lots of common security issues by using alternative data sources.