> so $700B in defense spending can't match some motivated, talented FLOSS devs? that's rich.
Not in my experience. The problem is not technical talent, it's culture.
That's not to say it's impossible to solve these issues, only that a culture of top-down "get it done" does not tend to mesh well with the rigid discipline needed to make a secure product. Ever had to say "no" to a general?
On any system built in house, there will be management feature requests which force security compromises. For example, "We must archive the data of this comms network - we have a legal requirement to do that!!" or "We need to ability to access user's data for internal/external investigations", etc.
Solving these issues in a secure manner is incredibly hard, and IME it can be incredibly difficult to explain to someone non-technical why "just do X" will harm the security posture. More often than not, a developer (with their salary paid by the boss) will be forced into "just doing X" by someone who does not truly understand how much that compromises the system. Boss will be happy, thinking they "pushed it through" and non-crypto developer will be happy thinking "it has some authentication applied so must be secure" while cryptographer will be largely ignored or misunderstood. (Note: not a cryptographer, but I am an expert in other domains and have worked with enough to see their pain first hand)
Most non-cryptographers on the project start to get confused, typically thinking all of the compromises are OK because they only open doors for the DoD and that is who the product is for, without having the training or knowledge to realize how problematic this thinking can be. IMO - listen to your cryptographer, you hired them for a reason.
Not in my experience. The problem is not technical talent, it's culture.
That's not to say it's impossible to solve these issues, only that a culture of top-down "get it done" does not tend to mesh well with the rigid discipline needed to make a secure product. Ever had to say "no" to a general?
On any system built in house, there will be management feature requests which force security compromises. For example, "We must archive the data of this comms network - we have a legal requirement to do that!!" or "We need to ability to access user's data for internal/external investigations", etc.
Solving these issues in a secure manner is incredibly hard, and IME it can be incredibly difficult to explain to someone non-technical why "just do X" will harm the security posture. More often than not, a developer (with their salary paid by the boss) will be forced into "just doing X" by someone who does not truly understand how much that compromises the system. Boss will be happy, thinking they "pushed it through" and non-crypto developer will be happy thinking "it has some authentication applied so must be secure" while cryptographer will be largely ignored or misunderstood. (Note: not a cryptographer, but I am an expert in other domains and have worked with enough to see their pain first hand)
Most non-cryptographers on the project start to get confused, typically thinking all of the compromises are OK because they only open doors for the DoD and that is who the product is for, without having the training or knowledge to realize how problematic this thinking can be. IMO - listen to your cryptographer, you hired them for a reason.