Some organizations do do this and they call them product security engineers or similar. Sadly, this doesn’t remove the need for an informed organization at larg

Some organizations do do this and they call them product security engineers or similar. Sadly, this doesn’t remove the need for an informed organization at large—that function covers a lot more than securing code—but it’s absolutely something that has been done. There is one caveat however: you’ll probably still need dedicated security analysis or security engineers outside the chain of command of your product or engineering org. There is a degree of necessary opposing pressures and incentives for infosec departments vs product departments: product organizations are rewarded for shipping more. Infosec organizations are rewarded for preventing incidents. The most common result of this contention are situations people often lament in the comments here—security programs that are either ineffective, heavy handed, or both. In my mind, a good security program positions itself as an enablement function and should strive to educate and inform over all else. People close to the work will be best positioned to make decisions about effective ways to harden their systems when informed of likely risks, requirements, or other security considerations. With any luck this minimizes the need to mandate security motivated changes and changes they dynamic when your local security professional comes by with specific concerns. It’ll be less of “the sky is falling” and more of “we saw this specific problem and would like to work with you to fix it”.