Architecture

In my years of working as an application security (appsec) penetration tester I’ve come to the conclusion that there are so much more value to be added than pure technical vulnerabilities. To deliver the most value you have to be willing and able to walk the extra mile. Before getting into what can be done to increase the value, let’s dig into the two most common types of vulnerabilities. Technical Vulnerabilities The technical vulnerabilities are the most common vulnerabilities we see....

We live in a world where technology compete for our attention, especially on our smartphones. Apps do everything they can to get us to open the app, and not leave it. At least that’s how I feel, with endless newsfeeds, notifications and autoplay, it’s so easy to just open the phone and get stuck. The feeling is not new, but the thing that pinned it down for me was the book Zucked by Roger McNamee [1]....

Technical debt has become a common term when discussing the quality and maintainability of code. There are a lot of definitions of the debt, but they all have some things in common, that debt are the things in the solution that should be fixed but haven’t been fixed yet. This could include everything from lack of documentation or test coverage to code complexity. The debt might not have been there from the beginning, but rather been introduce while the solution grows....