Andrew Rea

Andrew Rea

Stuff about programming, security and technical architecture

Andrew Rea



Government Digital Service visit

I went down to visit GDS (Government Digital Service) to understand a bit more about how they do things, the tools they use the practices they promote etc... I…

Andrew ReaAndrew Rea

I went down to visit GDS (Government Digital Service) to understand a bit more about how they do things, the tools they use the practices they promote etc... It was a great visit, great bunch of people and below are some of the things which really interested me.

The Pain Wall

Basically what it says in the image. This is a specific board for Tech Debt (in any area or a board per area) which I think gives real focus as this Technical Debt is being outed as causing pain which I think is really good. Ideally you would add Tech Debt to your board and adjust the priority accordingly but what I think this board does is it shows that the longer you leave the Tech Debt the more pain you are causing. It is not as obvious if you leave the Tech Debt cards building up in your back log or sitting low down in your input queue.


A constant threat to any company which has developers is ** THE DEVELEOPER **. What do they know, what could they do, would they do it, would they succeed? You can secure your company, your product, your systems all you want but there is always going to be a way your system can be affected by one or more memebers of the team. This is not to say this would happen it is simply a GAME to explore whether it COULD happen and if it did happen how quickly could the threat be handled and shutdown.

This GAME starts with a fictional story of one of the operations, developers, testers laptops get stolen. They haven't but that person simply goes into a room, shuts the door and literally tries to impact the Non-Live stages of the organisation using any means available to them. Some stories include putting up an OWNED banner where the staging server used to be, turning off accounts, stopping processes basically just running a muck. The game is literally to identify and stop that persons access and in turn any impact they could make in their organisation.

I thought this was a similar kind of thing to the likes of companies who test out there live service for failure and do it often so they are always aware they can deal with disasters of different scale. In turn chasing a disaster into a handled event. The same applies to this internal threat, they are holding their hands up saying "This could happen, if it did happen, let us explore some of the things which they could do and how we would handle it."

Security tooling

Some of the tools which they guys use in the security space were of great interest to me as most were open source and related to the work I am doing. I come across many ENTERPRISE products day to day and it is always refreshing to see the open source equivalents. I am far from being any sort of authority in the security space but I do follow good security practices in everything I do, so when someone shows me products and products they are using and getting great results from it is defintely something I take notice of.

One of the core things I am looking into is what kind of automated secrity testing I can put into my CI pipelines have them run nightly (some core and quick run with the commit suite) and cover all the core angles of application security. Essentially pushing Security to the left like we should with other cross functional testing.

Andrew Rea

Andrew Rea