Continuing with a commentary on NIST #appsecurity guidance, again, NIST reiterates what we recommended in Core Software Security and then updated (for Agile, CI\/CD, DevOps) in Building In Security At Agile Speed:<\/p>\n
\u00a0<\/p>\n
Threat Model<\/p>\n
Automate as much as possible<\/p>\n
Static analysis (or equivalent) SAST\/IAST<\/p>\n
DAST (web app\/api scan)<\/p>\n
Functional tests<\/p>\n
Negative testing<\/p>\n
Fuzz<\/p>\n
Check included 3rd party software<\/p>\n
\u00a0<\/p>\n
NIST guidance call’s out heuristic hard coded secrets discovery. Definitely a good idea. I maintain that it is best to design in protections for secrets through threat modelling. Secrets should never be hardcoded without a deep and rigorous risk analysis. (there are a few cases I’ve encountered where there was no better alternative. these are few and very far between.)<\/p>\n
NIST guidance is essentially the same as our Industry Standard, Generic Security Development Life cycle (SDL).<\/p>\n
There has been an implicit industry consensus on what constitutes effective software security for quite a while. Let’s stop arguing about it, ok? Call the activities whatever you like. but do them.<\/p>\n
Especially, fuzz all inputs that will be exposed to heavy use (authenticated or not!) I’ve been saying this for years. I hope that fuzzing tools are finally coming up to the our needs?<\/p>\n
https:\/\/www.nist.gov\/itl\/executive-order-improving-nations-cybersecurity\/recommended-minimum-standard-vendor-or-developer<\/p>\n","protected":false},"excerpt":{"rendered":"
Continuing with a commentary on NIST #appsecurity guidance, again, NIST reiterates what we recommended in Core Software Security and then updated (for Agile, CI\/CD, DevOps) in Building In Security At Agile Speed: \u00a0 Threat Model Automate as much as possible … Continue reading