Ask HN: Why arent developers interested in secure coding?
As someone who works in compliance, I have observed that many developers do not have a strong interest in secure coding. While Agile and DevOps have become widely adopted, security has not yet gained the attention of many developers. For instance, I learned about the OWASP project from security professionals rather than from developers. It appears to me that the development of secure software is primarily led by cybersecurity folks rather than developers themselves. Whats HN's view on this?
93 comments
[ 3.8 ms ] story [ 168 ms ] threadMost of the "business" people either think security is not very important or are not able to appreciate the work.
EDIT: Companies that really care about security have both external and _internal_ bug bounties. Internally you usually don't win money, but e.g. fancy tshirt, amazon voucher and you get placed into internal security wall of fame. At least you feel appreciated...
Depending on how you define this word (actual vs perceptual security) we would adjust the type of conversation accordingly.
A lot of "security" is theatrical crap that skilled developers don't have patience for.
Infosec team ran regular vulnerability scans and flagged our Go code as having a violation of some .net specific bug. They requested we fix it. Literally nothing to fix and no teams ran .net anything.
Another time, the security team discovered a bug in some open source MTA (mail transfer agent; email sending) and multiple times insisted we implement a fix. We didn't use that software. Worse than that, our company only existed because we wrote our own MTA, it was our core service and reason for existing.
At one point, a knowledgeable security expert was worth something. Now it seems to be checkbox driven.
I have heard similar stories from other people I know.
There is unfortunately for business an acute shortage of good security people. This works well for me of course, as I find myself in demand :)
When you have received a number of invalid URLs from an ip address then you shadow ban the ip address by sending "404 not found" back for ALL following requests from that specific ip address no matter if it requests a valid URL.
Now all the security checking is skipped because simplistic security testing looks like "yet another hacker".
The same kind of thing happens to certain managers and scrum masters that don’t get their hands dirty from time to time and have no feeling for what is bogging down the product.
When there is an economic reason to take security seriously, it is.
People are mostly motivated by gratification. You've written _functioning_ code - you can instantly see how it solves the problem at hand. You've written _beautiful_ code - you can stare in satisfaction at the negative total in `git diff --stat`.
You've written secure code - you reward comes in the form of nobody talking about your code for the next twenty years ;)
In short: Give me a threat model, by which I mean realistic groups with goals and capabilities, and we can mitigate the risks. Just talking about "security" in a void is pointless at best and harmful at worst, since ill-considered security measures have a habit of leading to even worse insecurity.
Which already defines many things what you should consider in securing.
It is not pointless to talk about just ”security” if there is any data which should not be exposed to another party without permission. But if there some other concerns instead of that, then it gets complicated.
Heh. Just realized this is true on many levels. For example, if you don't collect more data than necessary (per GDPR), there's significantly fewer things that you need to secure.
Thread models are important, but having a concrete adversary in mind is likely misguided. To whom you are an interesting target is hard to know and can change in a heart beat with economic or political events. You don't want to start looking for possible SQL injection vectors once you know someone is targeting you.
I agree though that three threat model should include damage potential and how sophisticated an attacker would have to be.
Except that SQL injection vectors are only considered an obvious threat for your example, because the associated concrete adversary is already well-known to everyone here.
The point is that without a realistic threat model, you have no idea where to draw the line. If you plan to try and anticipate every possible threat (because who knows if your app's data will be targeted by The Russians next week) then just unplug your hosting servers and put them in a locked room.
It's certainly worthwhile to think about, but the best approach is a bug-avoidance one where the tools guide you away from making mistakes but without constraining your ability to get things done too much.
TBH I think you are missing the point of threat modeling. It's not an exercise in determining the exact adversary you will face and what capabilities they will have. That is impossible to know with any precision. It's more an exercise in thinking through 1. What your assets are. 2. What attack vectors exist for compromising those assets and 3. What mitigations can be put in place for those attack vectors.
In doing that you may reasonably conclude that for a given attack vector, an adversary sufficiently advanced to pull it off would not be interested in you and that is fine. But you should still start from what you know concretely, which is what your system architecture and assets are.
1. What your assets are.
2. Who is interested in those assets.
3. What attack vectors exist that are feasible/available to the interested parties for compromising those assets
4. What mitigations can be put in place for those attack vectors.
Otherwise, as I said elsewhere, there will always be an attack vector, right up to the point where the computers are turned off and in a locked room. The only way to explicitly choose not to take that extreme measure is to figure out who you are, and are not, defending against.
Of course, the ‘who’ is part of that consideration of likelihood, but it’s not the only part.
> 2. Who is interested in those assets.
This is the wrong question to ask. The right question is how important is it to US to keep this asset confidential/available/unmolested. That is a question that is actually tractable and understandable. If you have a service where it is very important that it is always available, then you need to have mitigations in place to prevent DDoS attacks. Whether or not you have some hypothesis as to who exactly might want to attack you is beside the point. If it's important to YOU then you should just assume that there is some threat actor out there who will attack you. On the other hand, if it doesn't matter at all whether said service is consistently available, then it's not worth the time/effort/expense to put in place DDoS mitigations regardless of whether there is any threat actor out there.
Its about thinking what types of threat actor you might be exposed to. They all have different motivations and capabilities and resources. This can help you determine if it's worth trying to mitigate certain kinds of attack path, and how likely it is you may be exposed to them.
You can do threat modelling without considering threat actors and just focus on attack paths and asset values to prioritise or rule out any mitigations as well.
At the end of the day, there is no one true way to do threat modelling. Everyone has a slightly different approach. I'd say do what works for you, but be open to other approaches.
Absolutely!
As a security architect who comes from a dev background, I am acutely aware of the pressures devs are under to ship code. Even so, there are some things you should really try to write securely without a formal threat model.
As a professional you should at least be aware of common vulnerabilities in code and not blindly keep creating them, e.g. know your OWASP top ten if you're writing for the web or mobile.
I will bite here. Which ones exactly should be used and are not by common developer?
> know your OWASP top ten if you're writing for the web or mobile.
There is no "my OWASP top ten" and being able to list them helps zero in day to day coding work. The practical knowledge about secure coding does not come from OWASP. It actually typically comes from documentation of frameworks you use, their communication about their libraries and then knowledge about process.
I'm wondering how to bridge that gap so there is some assurance for the organisation as well as training for the developer.
Imo, the best security is the one that does not depends too much on developers remembering to do the right thing all the time. So for example if there is a method that leads to protentional SQL injection or XSS or whatever, prohibit its use and write unit test for it. Basically, static analysis of a code. So then, when someone accidently uses it, the test suite will complain. Hide unsafe things behind internal libraries that force developers do the right thing. Make the right thing easier then the wrong thing. The other good thing are checklists - checklist of ui code, checklist for API, checklist for database, checklist for configuration.
In my opinion, if you want assurance about something important, have checking it regular routine part of process and ideally automated. There is always someone who does not know or dont care or is just tired and not focusing. The best compliance is the one that happens automatically as the easiest thing to do.
In terms of the developer facing stuff, I'm keen not to repeat the sins of the past where security teams dump a whole load of well-meaning but practically useless stuff on them. As I say, I've been on the other side of the fence.
Management and compliance people want assurance that devs are aware of relevant secure coding techniques and pitfalls, but they tend to glom on to big, well known standards, even if half of it isn't useful.
I like the idea of finding coding examples relevant to the tech they use, that demonstrates insecure and then secure patterns. For the things that actually make a difference... And then to link the secure coding standards to that as well. Join it up, keep it relevant and practical. Then I just have to demonstrate that this actually meets what the compliance people want to see...
Now it has morphed into a much more abstract taxonomy of vulnerabilities and covers mobile as well as web. I think security people love this stuff, but it's much less directly useful to a normal dev.
It has very good brand recognition though! Even management types have heard of it, which is unusual for a security standard!
Good security: no one notices (unless you do activism for it in your company!)
Bad security: someone notices, but it's never an individual dev's fault
First of all, you see how things disappear from the list or go down?
Yeah that is because a frigton of opensource maintainers, usually unpaid devs just so you know, spend a lot of time making sure these attacks are impossible.
Like i am sorry but the whole software world is in love with Rust and spitting on C for a reason. We care a lot about security.
What we do not care about is something unactionable or unrealistic. And that? That is what security bring to the table.
Put it otherwise. Being big on the infosec workd buzzwords does not pay devs bills and do not generate money. So we solve the problem in our tools.
It just happens that this work is invisible to you and society in general.
Put otherwise. If we did not care about it, the list would be far far worse. Like we would not have TLS. Think about this a minute.
TL;DR: I bet most devs do care about security, but it's just one aspect to prioritize against other goals, and it's a task that can never be fully completed, not pro-actively without specific threats at least. You can never check that "this project is now secure against random attacks" checkbox.
DevOps is just a fancy word to signify that modern system administration requires coding proficiency.
Agile is a project management framework useful for IT projects.
I don’t see how those three phenomena are related?
This is almost but not quite secure code - the thread in common is that secure and robust code both have to sensibly handle and happily continue in a known state no matter what the input.
Hackers use fuzzers to concoct evil input that forces exploitable states.
The real world applies sod's law to any input that comes from sats, planes, instruments, etc.
Power flucuations, lightening strikes, disconnected wires left dangling and sparking, N+10 hard resets where N is a number so ridiculous nobody would ever turn it on and then off again quickly that often, ... etc.
When you circle back on any such signal collation for analysis, image generation, cross reference poor handling of unexpected input will cause such a mess that inevitably the habit develops to code excessively defensively, as too much paranoia is rarely enough.
If you can calmly think about something to automate, made good scenario, do some mental experiments etc than you can craft good code, witch happen to be also secure in general. But such model is long lost.
A lot of projects are just about showing the stakeholders the maximum possible and the rest is irrelevant. There is not enough time even for refactoring or paying a bit of the technical debt, let alone making the application safe.
So my conclusion is: calm programs only happen when people are willing to be more than users, to take ownership of them and agency in their evolution. And that's the kind of people I build for:
http://akkartik.name/about
http://akkartik.name/post/roundup22
https://github.com/akkartik/mu
Ultimately, meeting their compliance objectives and addressing the threats is their business.
We (infosec) can, and will help, but the outcome is their responsibility. We provide threat models, guidelines, patterns, and consultancy to the tribes if they need it (as well as SecOps, etc).
Ensuring the incentive model makes security part of the problem they need to solve we manage to avoid the constant fights - infosec is a "pull" service at the design stage rather than an endless, fruitless "push".
The real problem is that software development is an immature profession. It's a Wild West, anybody can identify as a developer. There are no educational or professional hurdles to overcome before you get provide your services.
No developer has gone to jail, or had their licence revoked for well-intentioned, but bad code. Incompetence is largely consequence-free, so the incentive for thoroughness is only present in the mind of the individual developer.
That said, security is difficult, time consuming and expensive.
And we don't know who's actually going to be attacking the internal software!
The security in our domain is so bad[1] that I think the only way to improve is via regulation. I can't for the RedDirective to be in force in 2024 and many products becoming illegal in EU. And I can't wait for the cybersec resiliance act to come into force to expand the RED directive to backend systems, and I can't wait for the Data Act to stop our incompetent middle managers saying "Data is the new oil" ...
While "compliance != security", the industry has done an abysmal job in coming up with better guard rails itself, so at this stage even a poorly written law is better than nothing. Most of my colleagues (who are still there) are so pissed with the internal attitude of companies that they openly joke that they hope the company get's breached because it's the only way management will learn.
firefighters and arson:
Until working in IoT I thought it's a strange coincidence that some fire-fighters are suddenly becoming arsonists.
The Blairwitch Project:
The behavior of the protagonists in that movie made me so upset that after the first 15 minutes I couldn't wait for the witch to arrive to kill them all. My job the bast 15 years was not unlike the first 15 mins of that film.
While I would never do anything to hurt these companies nor defend anyone who does, I do understand now a lot better why somebody is rooting for the witch to come or why a firefighter would set fire to a place.
The worst of it is that while 3 of us in a company of 80K employees are in charge of securing the product we will likely get hacked in the next 12-16 months. And even we informed management and continue to be gaslit by middle managers for "stopping progress" it will also be us who get blamed for not having done enough once the witch comes knocking.
That said the situation is even worse for players in the US who have great frameworks and standards but lack of regulation and binding laws.
[1] yes I'm speaking for the entire industry since I'm also chairing several industry alliances with a strong security track and have good insight over the attitude of most companies
Security is important but for most things it's not the most important thing. Useful but insecure can be used for something. Useless but secure can't.
so, my question is, where do i need to consider "security" in this situation, which is common in all the banks i've worked for?
I hope, it's still at least checking CORS headers, otherwise it might be vulnerable to a drive-by attack [1].
(At least if some device on the local network runs an older browser which does not implement CORS Private Network Access headers yet [2])
[1] https://wicg.github.io/private-network-access/#biblio-drive-...
[2] https://wicg.github.io/private-network-access/
That is how actual secure coding is achieved - by dealing with headers and requests in one standard well tested place. Actual new development is separated, so there is no need for someone working on trading engine to deal also with cors