3 ms·

I think it’s fairly simple - security often slows down development and competes with features. Product managers get their way, and features can trump bug fixes

by t34543 7y ago

I think it’s fairly simple - security often slows down development and competes with features. Product managers get their way, and features can trump bug fixes for far too long.

javagram 7y ago
Sometimes it’s the other way though, e.g. enabling a framework level XSRF protection mechanism is usually very easy for a greenfield project but it’s ignored by many developers in my experience until a security audit comes through and finds the problem - now every form in the app has to be re-tested to verify the mitigation was applied.
throwaway_bad 7y ago
Eh, can't only blame product managers for this. Developers don't like security features that make development slower either. I made the mistake of adding Content Security Policy to an app that was still in the prototype stage and it caused endless headaches whenever I needed to add new dependencies. Your app shouldn't be outright insecure, but defense in depth (e.g., security features that are only useful contingent on the presence of another security vulnerability) can be safely deprioritized until your app gets complex enough to need it.
- dspillett 7y ago
  > can be safely deprioritized until your app gets complex enough to need it I'd accept "until your app looks like it might leave proof-of-concept classification". And always be mindful of how quickly PoC code can magically end up needing to be production ready overnight or worse being in production before it is... Retrofitting security can be a nightmare, one that can be so easily avoided.
dspillett 7y ago
And in a situation where there are multiple products the matter gets more complex and competing priorities mean the wrong vice is made more often. I once nearly left a company because of being ordered to ignore a massive security problem in a legacy application that was actively used by many people to instead concentrate on tweaking bells & whistles on the shiny new thing that hadn't left prototype yet. That would have been fine if other resource was assigned to the security issues, but it wasn't. They did eventually see sence, but I didn't exactly make myself popular with the powers that be at the time.

by t34543 7y ago

I think it’s fairly simple - security often slows down development and competes with features. Product managers get their way, and features can trump bug fixes for far too long.

javagram 7y ago

Sometimes it’s the other way though, e.g. enabling a framework level XSRF protection mechanism is usually very easy for a greenfield project but it’s ignored by many developers in my experience until a security audit comes through and finds the problem - now every form in the app has to be re-tested to verify the mitigation was applied.

throwaway_bad 7y ago

Eh, can't only blame product managers for this. Developers don't like security features that make development slower either. I made the mistake of adding Content Security Policy to an app that was still in the prototype stage and it caused endless headaches whenever I needed to add new dependencies. Your app shouldn't be outright insecure, but defense in depth (e.g., security features that are only useful contingent on the presence of another security vulnerability) can be safely deprioritized until your app gets complex enough to need it.

dspillett 7y ago
> can be safely deprioritized until your app gets complex enough to need it I'd accept "until your app looks like it might leave proof-of-concept classification". And always be mindful of how quickly PoC code can magically end up needing to be production ready overnight or worse being in production before it is... Retrofitting security can be a nightmare, one that can be so easily avoided.

dspillett 7y ago

And in a situation where there are multiple products the matter gets more complex and competing priorities mean the wrong vice is made more often. I once nearly left a company because of being ordered to ignore a massive security problem in a legacy application that was actively used by many people to instead concentrate on tweaking bells & whistles on the shiny new thing that hadn't left prototype yet. That would have been fine if other resource was assigned to the security issues, but it wasn't. They did eventually see sence, but I didn't exactly make myself popular with the powers that be at the time.