From a security point of view, application logs are two-sided. On the one hand, it is really important to have good observability, to find out what is happening and what has happened. On the other hand, we don’t want to leak sensitive information. In this post I am going to look at the kinds of things you might find in your logs. The juicy bits are Personal Identifying Information (PII) or security credentials.

Let me tell you a story about Application Security (AppSec). It contains heroes and villains, and I’m not necessarily thinking about the defenders and attackers here. It contains lots of interesting technology that is often overemphasised. We’ve got whole industries that work on letting us know how scary it is out there, vulnerabilities that are marketed like rock stars and terminology that makes you quiver in your boots: who would want to fall victim to an Advanced Persistent Threat (APT)?

There’s a metaphor about the fight between attackers and defenders in the Denial of Service cybersecurity game. It’s an “arms race” between ever bigger attacks throwing huge amounts of traffic at ever more sophisticated defenses (e.g. AWS shield). Incidentally, I’ve just demonstrated an easy mistake: I’m not describing a Denial of Service (DoS) attack, it’s a Distributed Denial of Service (DDoS) attack. The aim is to overwhelm the infrastructure, either the networking infrastructure or the application by sending more requests than can be handled.

I am sitting on the train as I type this coming back from my first IRL conference. Lean Agile Scotland 2022 was brilliant. I met so many people with ideas that just chime with my thinking on agile, I feel energised and full of ideas No Bugs No Decisions No Deadlines No Fear What follows are some thoughts that I took away from some of sessions the conference. There were lots of exciting talks and workshops and it was a pity that I couldn’t clone myself to go to more of them (I was gutted to miss sessions that coincided with my own talk).

This is part of my series of interview questions for Agile India 2022. Thinking about exciting developments in software development as a developer immediately brings magpies to mind. What is the latest technology that can grab our attention. What’s the latest shiny? Could it be some crypto tech? Some no-code development? Or programming in the metaverse maybe? No, no, and NO! Crypto is a scourge that wastes energy, kills the planet and destroys lives, no-code and low code will mean some actual software engineers will have to pick up the pieces when it inevitably will go wrong and the metaverse (second second life) looks to be a great way to make the web as tedious to use than going to an actual shop where you can’t find anything because the items have moved to another shelf yet again.

This is part of my series of interview questions for Agile India 2022. It is difficult to articulate what the biggest challenge to software product engineering is, because there’s a fair few of them, so I’ll try to describe a few of my bug bears. Process over people In my opinion, a huge issue that we unfortunately find all too often is when the principles of the agile manifesto are ignored or not applied.

After being accepted for speaking at Agile India 2022 I was asked a few questions. I figured rather than a paragraph, the questions would make interesting blog posts: I came to agile completely the wrong way. I’ve been developing software professionally since I was a teenager and was lucky enough to start out with projects where I was given plenty of agency to decide on how to tackle problems and the independence to make my own mistakes and learn from them.

Dave Farley and Allen Holub are two people that I respect hugely when it comes to Software Development. I’ve been following them on twitter for quite a while, and am always taken in about their takes on driving continuous delivery and “lowercase agile” forward. So when both came together for Dave’s Engineering Room (sponsored by Equal Experts, who I work with), it was bound to be very interesting. In this post I try to outline my key takeaways from watching the chat.

I was really positively and pleasantly surprised when I found out what HMRC Digital’s mission statement was. Normally, I am not a fan of mission statements. They usually read like this: Our mission is focused on six core aspirations the company continually strives to achieve… Or some such drivel. Verbal gymnastics to make a company sound like everything to everyone - without being offensive to anyone - which then gets used to “align” people on mandated fun days.

In this post, I am going to look at an increasingly important part of securing applications: Your supply chain. This includes every library, tool or service that you are using to build, run and monitor your service. When the log4shell vulnerability hit, it wasn’t just a matter of looking at the dependencies that your source code pulls in, but also at the infrastructure you’re using and the build pipeline. Have you had a look at the vulnerability reports of your dependencies lately?