August 2016 Summaries

Threat Modelling For Node.js Applications` is a methodical approach to identifying and prioritizing security threats against a Node.js application, using attack trees as a formal framework for describing the security of systems. Attack trees provide a structured way to represent attacks against a system, with the goal as the root node and different ways of achieving that goal as leaf nodes. By assigning values to these nodes, such as possible (P) or impossible (I), attackers can be identified and defenses targeted accordingly. This approach allows developers to make informed security decisions by identifying vulnerabilities in their application and prioritizing defenses based on potential impact and feasibility. By applying this method to a Node.js application, developers can create an attack tree that highlights areas of high risk and informs the development of effective security measures.

ES2015 Proxy` allows developers to trap and manipulate property access, setting, has, and deleteProperty events on objects in a controlled manner, providing useful applications for testing, mocking, and monkeypatching, as well as abstractions over complicated concepts. A package `snykwire` is created to safely require modules by limiting their access to specific modules, utilizing the `Proxy` constructor with two parameters: `target` (the object being proxied) and a handler object containing spec for traps to handle. The `get`, `set`, `has`, and `deleteProperty` traps can be used to intercept and control property access, allowing developers to implement features like blacklisting modules and preventing corrupting of the module cache.

At Snyk, the engineering team focuses on achieving their goal of getting things shipped by adopting several practices that bind well and help them achieve this objective. The philosophy behind their approach is to always be shipping, making an impact on users, and using Continuous Delivery practices such as taking smaller bites when merging changes with others, moving faster with feature flags, and having good tests that are easy to write and fast to run. The team's agreement to ship fast is key, and they favor quick wins over complete overhauls. Their approach is not about making shipping a habit by proclaiming "Let's ship everything within 2 hours!" but rather about shifting hard parts to start as soon as possible in the process, understanding requirements and delivering value to users, failing fast, and having good merges that are no merges.