Maybe a way to help that would be to see if a library/framework is compliant. For example, Dream in OCaml automatically adds CSRF tokens to your forms https://aantron.github.io/dream/#forms which would comply with a subpoint of point 3.3. I took that example since OWASP compliance is one of the big points and it's not well known, I don't want to start a framework war here. Since there are constantly new developers, I think it would help to talk more and show more security best practices.
I think one of the key lessons here is that a framework fundamentally cannot be compliant. Too much of what is required is simply beyond what any framework can deliver and a matter of human-based process.
I have no doubt of the technical sophistication of Dream, but I do have some doubt that it provides a way to automatically assess the data handling of subprocessors for me (4.3).
I edited my comment to specify that I only talked about one specific point, I should have included that from the beginning. I agree with you, no web framework can ensure 4.3, but web frameworks could ensure/be compatible with 2.1, 2.2, 2.3, 2.4, 2.5, 2.7 (partially), 3.3 (partially). That's far from everything, but if all of that is automated, that's more energy that can be used for something else.
That's fair! I think you can get a lot of that from modern frameworks, provided you are willing to stick to their conventions and never deviate.
It's been my experience that sooner or later, every app has a reason to deviate. Maybe you wind up constructing a large analytical query as a string because nobody loves joining a dozen tables in an ORM. Maybe you find yourself stuck at a vulnerable version of a package because that branch has been EoL'd and the patched versions require major logic reworking.
So I think you're right - you can get a lot of the tools to be compatible with many of these items from a framework. I'm just not so sure about how much of that is automatically inheritable by an actual working app.
Comments
Maybe a way to help that would be to see if a library/framework is compliant. For example, Dream in OCaml automatically adds CSRF tokens to your forms https://aantron.github.io/dream/#forms which would comply with a subpoint of point 3.3. I took that example since OWASP compliance is one of the big points and it's not well known, I don't want to start a framework war here. Since there are constantly new developers, I think it would help to talk more and show more security best practices.
I think one of the key lessons here is that a framework fundamentally cannot be compliant. Too much of what is required is simply beyond what any framework can deliver and a matter of human-based process.
I have no doubt of the technical sophistication of Dream, but I do have some doubt that it provides a way to automatically assess the data handling of subprocessors for me (4.3).
I edited my comment to specify that I only talked about one specific point, I should have included that from the beginning. I agree with you, no web framework can ensure 4.3, but web frameworks could ensure/be compatible with 2.1, 2.2, 2.3, 2.4, 2.5, 2.7 (partially), 3.3 (partially). That's far from everything, but if all of that is automated, that's more energy that can be used for something else.
That's fair! I think you can get a lot of that from modern frameworks, provided you are willing to stick to their conventions and never deviate.
It's been my experience that sooner or later, every app has a reason to deviate. Maybe you wind up constructing a large analytical query as a string because nobody loves joining a dozen tables in an ORM. Maybe you find yourself stuck at a vulnerable version of a package because that branch has been EoL'd and the patched versions require major logic reworking.
So I think you're right - you can get a lot of the tools to be compatible with many of these items from a framework. I'm just not so sure about how much of that is automatically inheritable by an actual working app.