About... . . . .
...........time.
Open Web Application Security Project (OWASP) chairman Martin Knobloch wants security people and businesses to give developers respect and love rather than slating their work. The affable and knowledgeable German also wants to refocus the industry to talking about risk – a concept already embraced in other areas, such as …
treating others with respect? that's a wild idea.
a major problem in my opinion is that you can notice a leaky roof and businesses understand the concept of maintenance. Working vs not working is the only metric used by business and stale code - or old code in a new architectural landscape is not reviewed regularly (/ever)
maybe I should start my own company and call myself a code janitor? no. need a sexy name like "perpetual information assurance manager"
Developers are not always responsible for the shit that managers and marketing force them to write. Let us take the time to do it right, and not just squeeze out crap code to meet the unrealistic deadline, then let the customers test it for you, and the black hats test security for you. Let us take the time to do things a bit more generically at the beginning, so when the marketeers bitch and moan that this particular widget is two pixels too high, and not the precise shade of orange they didn't request in the first place, it wont take weeks to change.
Icon for the ranty nature of my comment ->
How about :
1. People managing software developers who know nothing about coding, and therefore have no clue what quality code even is.
2. Not asking basic questions at interviews so that you never even think about hiring someone who can't clearly explain what SQL injection is and how to prevent it.
3. Leaving hiring to HR who put their faith in shonky and expensive online coding tests rather than realising that it takes a great coder to spot a great coder.
4, Moronically obsessing about SCRUM-agile as your development path to Utopia, and being all smug about how you're achieving your weekly sprint, having implemented x bits of micro functionality, rather than producing quality code and eliminating technical debt.
5. Hiring cheap youngsters rather than experienced "old" devs, cos their willingness to do unpaid overtime can be exploited, forgetting that if you pay peanuts, you get monkeys
6. I could go on for quite some time here, but as a final thought : don't patronise us with this sort of "devs need some love too" bollox if you wish to retain talented dev folk and not be laughed out of the room.
Moronically obsessing about SCRUM-agile as your development path to Utopia, and being all smug about how you're achieving your weekly sprint, having implemented x bits of micro functionality, rather than producing quality code and eliminating technical debt.
Oh yes.
But everything needs a billable end customer, so there's no end customer for eliminating technical debt, yet all end customers benefit. So we just layer more and more crud on top of whatever it was the company was originally selling a decade or two ago, and we might even document it.
And then the marketing dept claims it's offering SaaS.
This post has been deleted by its author
This post has been deleted by its author
I recently had OWASP brought to my attention, someone was trying to use their security hardening guidelines for the postgresql database server... trouble was, that guide was written 10 years ago and hasn't been updated, while postgres has undergone steady and constant enhancement, with a major release about every 18 months, minor releases every month or two...
I'm all for educating developers more, but it is naive to think that education is the way to fix the problem.
The real issue is that security thinking is dramatically different than coding.
There are people who like to focus on all the ways that code can be broken, and there are other people who like to think of all the ways code can be used to implement some capability.
It isn't clear at all to me that both can be done, well, by one person - much less as an industry practice across tens and hundreds of thousands of developers.
The Cyber Independent Testing Lab with its UL-type approach probably has the right of it - flagging the most common coding conventions that are vulnerable, but it is far from clear that significant progress can be standardized at beyond their approach.
In the meantime, UL itself is getting into the game with a "standards-based" approach. Ugh?
The requirement to write secure performance code needs to be drummed in to dev's at the beginning of their career or it does not take.
Personally believe that the two are linked as if you do not understand enough of the architecture to understand why vulnerabilities office you don't have a chance of preventing them and you will also not understand why that god awful query joining two views across 12 tables is a bad idea.
Waiting until dev's qualify and assuming there will be a DBA / sysadmin to identify these issues is a none starter, especially for software houses. I'm personally writing this while my own DBA's & Sys Admins are helping a vendor fix the awful recent release we were advised to upgrade to which has made our production systems grind to a halt. At the other end of this process is giving project teams access to test automation and load testing products so we can stress test releases under performance loads rather than fire fighting when things go bad.
There are people who like to focus on all the ways that code can be broken, and there are other people who like to think of all the ways code can be used to implement some capability.
the trick to solve this is finding the devs prepared to do both and work out the ways that cant be broken consitantly.
Training is also key, you need programmers and not coders to devleop new systems. I e those that see the bigger picture, and can build an architecture, not those that can write a bit of code that does this.
Done right Agile/SCRUM can be secure, it just takes each devloper taking responsibility for their own code and someone taking responibility for the secure interchange between them.
I'll show more respect to the blundering coders and the idiotic profit-driven companies that are invariably the driving force behind such facepalms, when they start getting the basics right
What's more important, fixing your existing buggy code?
Or rolling out more features that basically introduces yet more bugs?
They all do this.... Oooooooh shiny
Obligatory Idiocracy quote: