The list of tools given in this article are more like components for developers to include in their projects. I believe that designing security and privacy starts with a threat modelling exercise which should come before and then as an integral part of the development process…:
[…] For these and other developer-oriented security products to work, they need to fit into the developer’s natural workflow (i.e., their preferred toolchain, among other things). They need great documentation, a consumer-grade experience (following Majors’ advice), open source (not always, but developers continue to love open source even in our cloud era), robust APIs, and more. If this sounds like too much, it’s not. It simply requires security to be considered as part of the application development process–that is, as part of the developer’s job–and not as an afterthought that “someone else” will handle.
It also means that selling such products involves, well, less selling. You don’t sell developer security on the golf course. You “sell” it in the docs and in the (PowerPoint-free) demos. You sell it, in other words, by simply making security a natural, built-in part of the development process; something that developers love to include. Going forward, this is what good security practice looks like.