7 ms·
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?
- draw_down 4y agoNobody gets promoted for writing the safest software. Safety is one of those concerns that has no real upside in an organizational context.
- 0xmarcin 4y agoThis, 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.
- deleted 4y ago[deleted]
- HatchedLake721 4y agoHonest question, what do you expect to happen after you find issues/bugs in the code you maintain?
- 0xmarcin 4y agoSomething 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...
- bob1029 4y agoWhat 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.
- null0ranje 4y agoThat's what happens when "cybersecurity" is taken over by the management consultant class.
- sethammons 4y agoThis 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.
- MattPalmer1086 4y agoYour 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 :)
- silvestrov 4y agoThere 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".
- bell-cot 4y agoIn 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?
- thunky 4y agoYup. When there is an economic reason to take security seriously, it is.
- christkv 4y agoI’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.
- crosser 4y agoBecause 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 ;)
- captainbland 4y agoMore 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.
- crosser 4y agoHeh 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...
- threatofrain 4y agoMost 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.
- yababa_y 4y agotell me about it. the digital supply chain is a travesty. everybody outside google just downloads brew.
- msla 4y agoBecause 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.
- nicce 4y agoIn 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.
- dmitriid 4y ago> 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.
- ajmurmann 4y ago"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.
- generalizations 4y ago> 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.
- errantmind 4y agoSimple answer: There aren't any incentives in place to reward it in most professional contexts.
- yellow_lead 4y agoYep. 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
- deleted 4y ago[deleted]
- layer8 4y agoI'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.
- di4na 4y agoA 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.
- flohofwoe 4y agoBecause '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.
- LudwigNagasena 4y agoDevelopers 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?
- defrost 4y agoThose 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.
- kkfx 4y agoWhen 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.
- lp4vn 4y agoExactly, 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.
- akkartik 4y agoThe 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/about http://akkartik.name/post/roundup22 http://akkartik.name/post/roundup22 https://github.com/akkartik/mu https://github.com/akkartik/mu
- herghost 4y agoWe 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".
- ghstcode 4y agoThe question should be: why aren’t project managers and product owners making security implementation and review part of the sprints as a priority item?
- secondcoming 4y agoI 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.
- gonzo41 4y agoI 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!
- jongjong 4y agoBecause 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.
- mkl95 4y agoNone 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.
- zabzonk 4y agoCompliance with what? What do you mean by security?
- DyslexicAtheist 4y agoBeen 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
- locallost 4y agoThat'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.
- thinkharderdev 4y ago"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.
- zabzonk 4y agothe 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?
- xg15 4y ago> 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-by-pharming https://wicg.github.io/private-network-access/#biblio-drive-... [2] https://wicg.github.io/private-network-access/ https://wicg.github.io/private-network-access/
- watwut 4y agoThat 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
- zabzonk 4y agodidn't use http
- generalizations 4y agoAs 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.
- rep_movsd 4y agoWe 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.
- fian 4y agoIn 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.
- bottled_poe 4y agoperhaps the question should be: why don’t investors allocate funds for secure software?
- groffee 4y agoSometimes 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.
- watwut 4y agoOWASP 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.
- indymike 4y ago> 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.
- bjornsing 4y agoMy 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.
- tomjen3 4y agoWe 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.
- goalieca 4y agoI’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.
- waspight 4y agoBecause 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.
- Kinrany 4y agoSurely it's not a surprise that security specialists have more interest in security than other people.
- analognoise 4y agoYou can get a bunch of useful shit done while ignoring the people in flowing robes yelling about how you "should" be doing things.
- antifa 4y agoWe 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?
- Brian_K_White 4y agoBecause 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.
- trashface 4y agoWhy isn't the C-suite interested in secure coding?
- mikewarot 4y agoSecurely 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)
- lovelearning 4y agoDuring 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.
- mamcx 4y agoYou 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.
- karmakaze 4y agoJust 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.
- yellowapple 4y agoI'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).
- moloch-hai 4y agoGenerally 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.
- pan69 4y agoYour 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.
- deterministic 4y agoBecause 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.
- qwerty111111 4y ago[flagged]
- qwerty111111 4y ago[flagged]
- qwerty111111 4y ago[flagged]
- qwerty111111 4y ago[flagged]