Seth Hanford 🐡 on Nostr: nprofile1q…ufle4 sorry, I haven't spent a ton of time looking at the CISA SbD ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq7yf7cxzxz4kwf24zmflvyqqtrylsjwm5q9a074u5ger57rmzz0aq0ufle4 (nprofile…fle4) sorry, I haven't spent a ton of time looking at the CISA SbD principles, so I'm just riffing off of what I tend to think about secure by design approaches in big business and I can't answer "wouldn't SbD apply on the supplier side". I guess it would? My experience is that internal product security teams do a lot of eg SAST/DAST work to identify coding flaws and correct vulnerability types in first-party code.
Yes there are configuration issues (don't write secrets to files and check them into repos; don't deploy third-party code running as root) but a lot else is "don't implement SQLi flaws; don't implement deserialization flaws; don't implement auth bypass flaws".
What I was wondering in my first post is more like "as a security leader at a large-first-party-code org: when is it greater risk reduction to invest in secure code production vs. secure configuration implementation/ configuration drift detection". It feels like it's much later than many orgs choose or the investment ratio should be much higher in secure config, but I don't know of data that backs that up.
Yes there are configuration issues (don't write secrets to files and check them into repos; don't deploy third-party code running as root) but a lot else is "don't implement SQLi flaws; don't implement deserialization flaws; don't implement auth bypass flaws".
What I was wondering in my first post is more like "as a security leader at a large-first-party-code org: when is it greater risk reduction to invest in secure code production vs. secure configuration implementation/ configuration drift detection". It feels like it's much later than many orgs choose or the investment ratio should be much higher in secure config, but I don't know of data that backs that up.