We've heard of that. But it's expensive and we don't have the budget for it this year.
- manglement as usual.
The Python Package Index, or PyPI, continues to surprise and not in a good way. Ideally a source of Python libraries that developers can include in their projects to save time, PyPI has again been caught hosting packages with live Amazon Web Services (AWS) keys and data-stealing malware. Malicious packages are, sadly, nothing …
Security can improve if you hire a hacker to work on everything you do, to try and hack it, but then since they are your employee they can reveal how it's done and everyone can work to stop it ... but keep trying in future - that's hopefully security. Security may exist if your hacker fails to hack items but keep trying.
"I believe a fair bit of the blame can be laid at the feet of developers, but this sort of thing may not be part of their core competency"
never was truer word said.
Security needs to be a core competency, but interviews for high skill jobs are just a self fulfilling prophecy in that you get you developer to interview the next developer and so on, and if that skill set or you SecOps/InfoSec dude is not on the interview panel it is unlikely any security competency questions will be asked, but then how many Info sec people understand programming enough to be able to ask relevant questions? "this sort of thing may not be part of their core competency"
I don't think it's reasonable to expect all software developers to understand everything they use. That would be like demanding that electricians build their own soldering irons and power supplies.
For software development to thrive we have to have tools that can just be grabbed off the shelf and slotted into place. The fact those tools can't be trusted is a serious concern but I don't think that expecting every software developer to understand what those libraries do is the answer. The answer is to come up with a system that ensures we can trust those libraries.
I would expect a competent one to be able easily to design and/or construct both of those items.
I'd have thought someone as pedantic as you would have read my post more carefully. What I actually wrote was:
That would be like demanding that electricians build their own soldering irons and power supplies.
Electricians buy the tools and equipment they need without (by and large) wasting their time worrying about how they are constructed. Software developers should be able to do the same with libraries.
Human innovation has always been about wrapping complicated things up in ways such that other people can use them without need to expend the effort gaining the same knowledge. I don't know enough about the internal combustion engine to repair one but that doesn't stop me driving a car. Although I know a lot about telecommunications most people do not and it doesn't stop them using a telephone.
The whole point of a software library is to allow a software developer to leverage some other developer's skill and knowledge. Requiring a user of a library to validate the contents of that library is a poor use of their time.
Based on what we're seeing, I'd say it was nearly a required use of their time. To use a car analogy, if you outsource your rims, and the come back square, you know something's wrong. But if you outsource, e.g. download a library, it would seem to me that you'd verify that it does what it says on the tin. If it makes an unexpected gethostbyname query using base64($key).miscreant.tld, you have a problem.
One of the best sec courses I went on the tutor said on the first day.
If you ever want to play with some interesting tech and you can't afford it then just poke about Github for around 30-45 mins and you'll find no end of logins, passwords for all sorts of access to services for free, code repos are the best places to find free logins! I'm joking of course, don't do that however....I'm just telling you the honest truth. If you want to litrerally set fire to the company's money by letting people with fewer morales than you have a fun time playing in your cloudy services backyard, then go ahead use public repos like Github to store your company code 'cos I can garantee that within 3 months one of your devs will put keys and logins into code and your cloud costs will literally go up by 10, 20 or 50 times over a couple of days and the company will have to pay for it if the provider finds you let your keys loose in the wild.
Ban Python! I mean it, ban it, and all other languages while you're at it. No-one should be able to run code of their choosing on their machine. Code should be uploaded to the operating system manufacturer for approval, who in turn could say upload it to an official app repository. Only official app repositories should be allowed. "But" you say "this will put a strain of the OS manufacturers resources!". I hear you, so the manufacturer should be able to charge a small amount for his services, say $99 per year. Ongoing charges could be a reasonable 30% of the apps turnover. They could also provide a single service for credit card processing too with all the security benefits that provides. Everyone's a winner!
"I believe a fair bit of the blame can be laid at the feet of developers, but this sort of thing may not be part of their core competency – security is hard to get right at the best of times,"
It ain't hard to store your access keys in Secrets Manager and retrieve the keys when you need them programatically, then rotate those keys on a regular basis and make sure the keys you are using ONLY have access to the resources you need.
This is just lazyness and/or blatent incompetance!