Ask HN: Why arent developers interested in secure coding? | Hacker News Reader

Ask HN: Why arent developers interested in secure coding?

32 pointsarunsivadasan87 comments

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?

View on HN

Because security without a threat model is an endless well of paranoia that leads to mere paralysis, an inability to change because of some infinitesimal chance that someone with unguessed capabilities and unclear goals might subvert a fundamental part of the system.

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.

In Europe you don’t need to look further than legistlation.

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.

> In Europe you don’t need to look further than legistlation.

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.

"Give me a threat model, by which I mean realistic groups with goals and capabilities, and we can mitigate the risks."

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.

> You don't want to start looking for possible SQL injection vectors once you know someone is targeting you.

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.

I think you can make that decision without knowing the concrete actor. Instead of asking if Russia has a concrete interest in hacking my product I can ask if it's worth it to protect against all possibly attacks from nation state actors. For almost all applications the answer will be "no".

From a different angle threat model is basically disseminated bullshit in order to make you believe that there are actors whom you cannot oversmart/protect against. In essence you are running in a rigged environment, and better accept the "common truths"...

Yes. Security, like legal compliance, GDPR, etc, is focused on minimizing risks. The least risky strategy is to do nothing: write no code, ship no product, have no users. Therefore it's a constant pressure against delivery.

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.

> by which I mean realistic groups with goals and capabilities

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.

You missed a step there. It's actually closer to:

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.

Instead of focusing on ‘who’ specifically, step 3 of threat modelling actually focuses on the likelihood of something happening and the impact of it does. From that you can determine whether the cost of applying the mitigation is ‘worth’ applying in terms of reducing the impact of the threat to an acceptable level that the business can accept.

Of course, the ‘who’ is part of that consideration of likelihood, but it’s not the only part.

I'm not sure we actually would disagree on anything concrete but for the sake of argument:

> 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.

I think the who question is not so much about determining exactly who might attack you.

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.

> 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!

While it is true that a threat model is really needed to inform prioritisation of security controls and other mitigations, there are many secure coding techniques that developers should be using, but clearly often don't.

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.

> there are many secure coding techniques that developers should be using, but clearly often don't.

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.

That's interesting, thanks. I can see how practical techniques will make most sense if they are closer to what you're doing.

I'm wondering how to bridge that gap so there is some assurance for the organisation as well as training for the developer.

What it is that you want to teach them in the training? I mean the question genuinely, not as a snark. I am curious about what you (or other security people) see as missing part. I have seen security audit of what we were working on done few times and found it interesting to read. It is good to put that stuff into training materials and repeat it to people. It is actually cool if you can demonstrate attack on their own software (there is always someone who will call your attack theoretical until you demonstrate it).

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.

I'm currently working on SDLC security. There's lots of different pieces: peer review, secure code review, threat modelling, training, secure patterns, coding standards, static and dynamic analysis, software composition analysis, build pipeline security, and pen testing! And a bunch of other things to think about.

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...

I hear you on OWASP in fact. I think the earlier iterations of it were more useful to developers. It focused on very specific vulnerabilities and it was a lot more concrete.

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!

What is your definition of "secure"? Ticks all of your audit checkboxes, or can actually resist nation state tampering?

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.

That's what happens when "cybersecurity" is taken over by the management consultant class.

This hits home for me. Two cases leap to mind.

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.

Your security team is either incompetent or made powerless themselves by unthinking compliance tick box people. And frankly I'd go with incompetent as they should be able to make a risk argument that there is no risk!

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 :)

There is an even worse scenario if you try to stop brute-force hacking of product URLs:

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".

Ha, yup. We had metrics for any endpoint that was attempted and we got paged for zounds of 404s being generated. We thought it was an attack and reached out to our infosec team. "We are scanning for vulnerabilities." They wouldn't stop the scans so we had to stop alerting on 404 spikes. After, we have no way to detect an actual nefarious scan. Yay checkbox driven compliance.

There’s many companies where security engineers never write a line of code and never pen test. They can be caught up in process and theory in the same way some scrum masters can. They often lack an understanding of the code and architecture and don’t have a feel for the situation in the ground.

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.

That's a loaded question if I've ever seen one. Developers care about a lot of things, including security. Most of them care way too much. Sometimes they even deliver things that are crappy to use because it was a challenge to get it done at all. Doesn't mean they don't care about users either.

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.

"Security" is not an atomic property of software. And while there are a lot of difficult tradeoffs between security and usability there are also a lot of low hanging fruit where entire classes of threat can be mitigated with zero tradeoff for user experience (and sometimes zero tradeoff for developer productivity if the system is built from the start with security in mind). To take a trivial example, hashing (with an appropriately secure algorithm) and salting passwords stored in your database. Or using prepared statements instead of manually building SQL queries. These are things that can effectively eliminate entire classes of vulnerability and are basically free to do.

A few things.

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.

In a "fake it until you make it" world, where being first to ship seems to have huge upsides, and massive security breaches seem to have minimal downsides - why would a rational developer, manager, or organization actually care about security?

Yup.

When there is an economic reason to take security seriously, it is.

Because of delayed gratification.

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 ;)

More likely the reward is people complaining about how inconvenient the new security process is for the next 20 years. "Oh I have to rotate keys now..." "I liked it better when it told me my password was wrong outright" "entering an MFA token from my phone is annoying" etc.

Heh that may be true sometimes. Though in my perception, "writing secure code" is more about sanitizing input and preventing buffer overflows than about enforcing secure practices on the user...

Most developers don't get to choose development priorities. Their gratification comes from a salary which may or may not rise by unknown proportion based on deltas in performance. The "real" incentives behind company performance are generally not owned by developers to any emotionally substantive extent.

Been working in IoT and industrial IoT for over a decade. My job title always had security in it.

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

In my current role I work as a developer in the finance sector. We are interested in secure coding. Every year we have to complete a secure coding course and pass an assessment.

We have a team dedicated to performing security reviews for most code changes. Your change can't go to Production until it has been assessed by someone from the secure code team. They can request rework if they think you have introduced a vulnerability.

We have regular pen-testing performed.

There are various vulnerability scanners running against the code repos and blocking builds if a dependency is identified to contain a new CVE.

The project I mainly work on has been in active development for decades. It has well defined frameworks for many common actions. Most of the time we are working within those frameworks, which have been already been vetted thoroughly. Ironically, it is rare that we would need to touch code in a way that could introduce a vulnerability.

In a previous role I worked on desktop applications for engineering simulation. There was no requirement for secure coding for those projects as there was no central database. All the models were file based.

So it depends on the project and the risk and consequence of an malicious actor finding a vulnerability and exploiting it. The health and finance sectors have to take secure coding seriously. From experience, many Oil and Gas companies are also super strict on controlling data access and will often request proof that a software application has been security reviewed and pen-tested.

I’ve been a developer in a security champion like role for many years now. I’d first like to say that developers are casually interested in security and will try to do the best they can. I’d say the interest in security is about the same as in technical debt. The same kind of risks are assumed and the same difficulty in saying no to product owners also exist.

Simple answer: There aren't any incentives in place to reward it in most professional contexts.

Yep.

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

None of the companies I have worked for encouraged secure coding. At most places you won't get any recognition for going the extra mile to write secure code, and in fact you will usually be encouraged to cut corners at the expense of security to deliver stuff faster.

The question should be: why aren’t project managers and product owners making security implementation and review part of the sprints as a priority item?

> As someone who works in compliance, I have observed that many developers do not have a strong interest in secure coding.

This is just selection bias. Your job is to make people comply, most likely with something that hasn't been a priority until something happened to make it a priority. If you have a team built around shipping lots of functionality quickly, well, you are going to get a lot of blank stares when you start slowing things down. So, compliance is a hard job. And people who haven't made security a priority over time are not going to have much awareness of best practices, or OWASP.

> 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?

If you want to shift from "move fast and break things" to quality + security (which are peas in the same pod), it will often take new leadership. The processes, people, systems, and culture will need to change a lot. An observation: being good at finding problems is not the same as being good at fixing and preventing problems, and this where you have to be careful when you are changing leadership. It's not as simple as hiring a certification. It's actually a big organizational challenge.

Because it's uninteresting except to some small subset who just happens to find that an interesting problem they happen to like to work on.

Everyone has their own particular things they happen to become interested in, so some few people are into security, just like some few are into stamps.

But outside of that, security is merely important, not useful or interesting or productive or functional or cool or fun.

Fundamentally the useful function of any machine is to do something. The problem that is interesting and fun and gratifying to solve is how to get that something done at all.

Other considerations like optimizing the design for some parameter like manufacturing cost or materials availability or reliability or field repairability, or writing the documentation, are all secondary puzzles that can be gratifying but are far less so than the initial creation. It's gruntwork and 'mere engineering'.

Figuring out how to ensure that the machine can only be used by approved people in approved ways at approved times and log all activity for auditing... that is even less interesting than optimizing or documenting, unless that just happens to be your kink.

It's hardly a boggling mystery. It's like asking why developers don't seem to like meetings and 7 bosses.

When you develop in a rush, SCRUM style, perhaps in the stereotypical silicon valley mode, you can only spit out code, your goal is just to be quick and achieve some apparent level of usability.

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.

Exactly, OP probably lives in a bubble.

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.

The way I think about it is: I can either program calmly for myself or in SV mode for millions of "users". And when I look around, my dilemma seems fairly common. Programming for lots of people is inhuman. I don't yet know how to program calmly and get to something others find useful. It takes too long, nobody will fund it, I can't convince others to join me, even I can only devote limited time to it.

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

I'd already be happy if all developers would be interested in well-behaved code that covers all possible edge cases, and not just the expected input/states, and would think in terms of well-defined software contracts between modules, objects and functions. Coincidentally, that would also take care of certain classes of security issues.

Those who write 24/7 continuous pipelined processing numerical code for signal process and instrument monitoring are very interested in robust code.

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.

Developers write code to meet requirements. People like product owners, cybersecurity specialists and technical analysts provide those requirements.

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?

I’m going though the performative bs of providing documentation for this to a tender and it’s all about the documentation not about the actual handling of security. They just want a set of documents so they can blame somebody else. Thankfully we use azure so we point the finger at them for most of it lol.

I get work from IT security. I don't have IT security create less work for me. And the benefit they create in my work is .... lots of sonarcube scans that create work items for me, that may more maynot be real.

And we don't know who's actually going to be attacking the internal software!

During my formative years as a new SE, our focus - mine, the team's, the managers' - was always on functionality and features. I was coding with C++, Java, and Python in those places. One of those companies sold (and still sells) critical equipment that's quite close to all of us :). Security was either a secondary concern or the responsibility of a dedicated team who were part of deployment.

It's only gradually, over many years, that I built up my knowledge of secure coding, especially after I started dabbling in front-end web development.

I'd have thought things have improved now because web and cloud are the first choices everywhere. But after seeing your post, I'm wondering if what I experienced is still the norm.

As someone who works adjacent to compliance, I have no interest in "secure coding" as you describe it because it's bureaucratic security theater - better for avoiding liability than actually being practically useful.

You are thinking TOO high (OWASP, compliance, etc.).

This must start at the bottom: The language, the DB/Store, Privacy, the management of secrets.

Only recently this more or less have start to get some traction (Rust, Apple insistence, etc).

But as long JS, C, Java, C++ rule and they don't have "secure code per default" and "the login sample use proper APIs" everything else is impossible.

We hire an external pentest firm once a year to tell us what to fix. Those changes are also inforced by updating our automated tests. I watch pull requests diligently to make sure juniors aren't creating SQL injections or more obscure security smells, or things that might cause the pentest firm to doc us points.

I'm a regular dev. Anyways, what specifically are you suggesting?

Your question statement is simply not true. Developers are interested in secure coding.

The problem is that you spend your days in a niche, a relatively well defined and limited scope, i.e. "compliance".

Developers on the other hand are working in a much broader context, i.e, working through the requirements, architecture and design, project management (who's doing what and when), the actual implementation, finding and fixing issues, etc, etc. And of course, compliance.

I totally agree, and I am pretty sure that any developer will agree that compliance and security should not be an afterthought but it just happens to be that in your world compliance is the most important thing. So, why is not not for everyone else in the world?

Maybe you should actually be working on projects with developers so that you can lead and help the team in this space? In any team you see that various individuals have slightly different specializations, yours could be compliance and security. This would help a team.

We do: almost any framework will prevent sql injections automatically and the same for things like CSRF or HTML injection.

What we don't do is have a checklist to go through. We haven't considered these things, because we have _eliminated the posibility_ of that particular issue.

That doesn't mean it is always safe: it just means that there new and exciting hacks to discover.

Just because you have observed many without a strong interest in security, how would you know that there isn't also many who do? I do, but I wouldn't say strong interest because I don't encounter it in my day to day.

As an implementer of APIs, most security concerns are done during auth. The only usual things are care in handing of externally supplied values (e.g. database ids or strings) and maybe redacting some parts in logs. Every now and then a new thing gets made that needs its own set of permission scopes and assignments to apps etc.

> development of secure software is primarily led by cybersecurity folks rather than developers themselves

"cybersecurity folks" who develop secure software are "developers". What you're really saying is that app feature developers, etc don't focus on security, which they should but only as much as they need to which isn't very much.

Because 'security' is fractal in nature and affects every little detail down to the hardware level (where even our lord and saviour Rust cannot help). No matter how secure your code or hardware is, there will always be an exploit waiting to be discovered. When this inevitably happens the security 'extremists' come out of their holes and yell 'I told you so', which is not exactly helping the cause ;) Meanwhile devs need to prioritise time spent on security versus product features and actually getting shit done.

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.

Securely multiplexing the hardware resources of a computer is the job of an Operating System, not applications. There is no effective security implemented in our operating systems as they are currently offered. There hasn't been since IBM XT machines with dual floppy disks and MS-DOS.

I can hand a stranger $5 without having to trust them with access to my wallet.

I doubt anyone, other than Jart*, can show me how a user can hand a document to a program they don't trust, without risking all of their stuff (and the OS) in Windows, Linux, Mac that is just as transparent and easy.

You want programmers to spend time and effort routing around missing security infrastructure, which is always going to be futile, and they know it instinctively.

*Because running a Linux executable in a browser offers a path towards LPE (Least Privilege Execution)

I'd say quite a few (most?) of us do have an interest in the most secure form of coding there is: write as little of it as possible, and work with as little data as possible.

Unfortunately, we live in a real world with endless corner cases, so real-world software ends up having to address those corner cases - meaning more code, and more data to work with. Such software is also rarely unburdened by deadlines and prioritizations from management - meaning that as much as programmers would like to pursue security hardening, there's rarely time to do so.

In other words: you're barking up the wrong tree. Take it up with my manager/customer/etc. demanding I devote my time to new features instead of even so much as tech debt reduction (let alone actual security hardening).

Because 99% of “cybersecurity folks” that I have dealt with in the past were incompetent bureaucrats or (worse) consultants who had zero clue on how to actually make systems secure.

All they did was to email checklists full of demands for specific tech or protocols to be used that either was completely unnecessary, actually wouldn’t work for our project, had publicly known security issues, and/or would not make the system more secure. They almost always had no clue when I asked them for the threat model they were basing their demands on.

Don’t get me wrong. I am sure that there are competent “cybersecurity folks” out there. I just haven’t met a single one in my 30+ years career. YMMV of course.

the last major piece of software i worked on was a server that performed equity trades on some major european stock exchanges (london, paris, milan, frankfurt) and with some third-party brokers. the software ran on machines in the bank's own datacenter and could not be accessed from outside (it didn't take incoming requests from anything except the bank's internal physical network, though it did take fills from an exchange in response to a trade). the server had to comply with the rules of the various exchanges, else the trades would not go through.

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?

> it didn't take incoming requests from anything except the bank's internal physical network

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 sort of stuff is usually dealt with at application server or somewhere around that level. The developer working on rules themselves is never encountering http requests themselves. Or very rarely.

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

didn't use http

I don't think it's fair to say people aren't interested in it.

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.

We have devolved responsibility for secure code to the product owners.

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".

We had our 7 year old platform audited by a security team. They found about 2 errors related to some APIs leaking some info - like whether a username existed They found 3 to 4 issues with the server config like using older SSL algorithms or exposing the servers identification (like nginx)

None of these could really be used to exploit anything.

If you just follow some common sense and start with a good architecture initially, security isnt something that needs extra particular attention.

My background is in engineering physics and I like to think from first principles. I make a strong distinction between the possible and the impossible. In my experience the cybersecurity folks tend to think very differently, in a more fuzzy / pragmatic way, and it’s very hard to translate their thinking into sound engineering. They are typically very focused on trivial aspects, which goes poorly together with good engineering culture.

Sometimes there has to be a trade-off between user satisfaction and security.

If you make a process with too much friction, it might be secure but you'll get user churn. Plus a lot of end users are straight up idiots, making something too secure means a lot of them won't be able to use it.

But that said the only time I've seen insecure coding in the wild is the endless blog spam on sites like medium etc.

Compliance with what? What do you mean by security?

Because you never reach any goals that get verified if you develop for security. It is like you only getting punished if the security is weak (you get exploited), but you never know if the security you implemented actually prevented a threat. So there is no real rewards.

Would be interesting to know if there is some kind of reward model out there that solves this.

OWASP in not really targeted at developers and a lot of in it is just not actionable or useful for Tommy implementing new basket. The parts useful for developers are known by developers

OWASP is for security professionals which is why you heard about it from them.

Because secure code means simple code. Most developers are interested in producing complex code because it's easier to write (requires less thinking/planning) and it makes them harder to replace within the organization.

Why isn't the C-suite interested in secure coding?

You can get a bunch of useful shit done while ignoring the people in flowing robes yelling about how you "should" be doing things.

Surely it's not a surprise that security specialists have more interest in security than other people.

perhaps the question should be: why don’t investors allocate funds for secure software?

tell me about it. the digital supply chain is a travesty. everybody outside google just downloads brew.

Nobody gets promoted for writing the safest software. Safety is one of those concerns that has no real upside in an organizational context.

This, I once found and reported a security issue in the code. The prize that I got was to late Friday evening spend of fixing the issue while deploying all 20+ microservices.

Most of the "business" people either think security is not very important or are not able to appreciate the work.

Honest question, what do you expect to happen after you find issues/bugs in the code you maintain?

Something like "Wow! great that you find it!" or "God job, remind me about this when we will be doing yearly salary review" or "Get this fancy tshirt"... What I instead encounter was "Fix it! It's your problem now..."

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...

Generally it is management who are least interested in secure coding. It costs time, and they generally are unwilling to allow time to do any of it.

Reply on news.ycombinator.com