[posixplz]

Software security architect here. Senior management strongly discourages writing code on my team. But this is because we work at-scale with hundreds of products comprised of thousands of microservices.

I don’t attend product teams’ standups , but our engagements run on the order of weeks to months.

We don’t micromanage development or design choices made by product teams. Yes, we review code and make (strong) suggestions, but we leave service teams free to make choices as long as the risk is low and commensurate with the threat model. It’s our job to guide major decisions and, occasionally, advise on the “least-bad” short-term solution, pointing out where, when, and why a re-architecture will be required in the future. Generally speaking, teams want our feedback on design proposals and concepts. It’s a healthy relationship.

Occasionally we have to force teams to reimplement, or block release, but that’s a very rare occurrence.

Unlike many comments on this thread, service teams leave us with pretty positive feedback. It’s very rare that teams leave negative feedback on our design engagements.

[justicezyx]

AFAIK security people usually is consulting on security issues and rarely dictates implementation details.

This IIRC is not the OP referring to.

[adrianN]

IMHO it is often the case that security can only be achieved if the design is sound. Overly complex designs are very hard to make secure.

[justicezyx]

Sure, but still they do not dictates implementation details. And that's different than what OP saying.

[posixplz]

That’s definitely the case when thinking about security in a strictly limited scope. In contrast, my team is holistic — any issue that could affect ICA (integrity, confidentiality, availability) is in our purview.

My team engages in the earliest phases of design. Holistic security is our priority, but not a limiter for our engagements.