process

Upping Your Web Security Game

Guy Podjarny sounds a sober warning during our festivities, and gathers some winter fuel to help secure your apps and users from the web’s occasionally cruel frost. So mark his footsteps good, my friend, and tread thou in them boldly. Thou shalt find the hacker’s rage freeze thy site less coldly. When I started working in web security fifteen years ago, web development looked very different. The few non-static web applications were built using a waterfall process and shipped quarterly at best, making it possible to add security audits before every release; applications were deployed exclusively on in-house servers, allowing Info Sec to inspect their configuration and setup; and the few third-party components used came from a small set of well-known and trusted providers. And yet, even with these favourable conditions, security teams were quickly overwhelmed and called for developers to build security in. If the web security game was hard to win before, it’s doomed to fail now . In today’s web development, every other page is an application, accepting inputs and private data from users; software is built continuously, designed to eliminate manual gates, including security gates; infrastructure is code , with servers spawned with little effort and even less security scrutiny; and most of the code in a typical application is third-party code, pulled in through open source repositories with rarely a glance at who provided them

More: 
Upping Your Web Security Game

process

Why You Should Design for Open Source

Jina Bolton lets the Christmas spirit of generosity and goodwill flow freely into open source projects in need of good design. It’s work free of charge, perhaps, but not for nothing.

Originally posted here: 
Why You Should Design for Open Source