Our IT Security and Risk (ITSR) team is almost invisible to the outside world, yet is quite influential amongst our technical teams. The ITSR team is constantly searching for patterns to improve our security posture, and proposes—and sometimes implements—approaches to ensure that REA Group’s infrastructure stays as secure as possible.
In this article we will uncover some “behind-the-scene” approaches implemented by the ITSR team as a proof-of-concept solution to showcase the technology.
In the modern world it is almost impossible to create an infrastructure purely based on the “in-house” solutions and products where every single line of source code was audited. Therefore, companies are relying on a myriad of third party components which source code is either inaccessible (e.g. proprietary software) or was not audited.
To make the matter worse the majority of vendors do not follow IT Security best practices and their products are usually using excessive sets of privileges. For example, instead of providing an SELinux policy module tailored for their application they simply state that the first installation step is to “disable SELinux”. This approach is clearly understandable from the business point of view (e.g. the support cost is lower), but is not acceptable from the security point of view.
In part one of this blog series, we introduced a monadic macro from the Each library, and showed how it can simplify asynchronous operations. In part two, we will investigate how to gain testability without mocks and stubs, and still keep transparency from the business point of view.
Two years ago, Ken Scambler wrote a blog To Kill a Mockingtest,
which describes why we should use the command pattern to wipe out side effects and enhance testability. In this article, we will see how to implement the command pattern with the help of Scalaz and the Each library.
What we do here at REA is super serious business, but I came to REA for a different reason entirely. Because of technology. It has the capacity to be creative, fun and simultaneously, it can deliver value.
It is no secret we have a lack of talent coming into IT here in Australia. I believe that the reason behind this is how software development is perceived in the community. Hacking in popular media is presented as a Matrix-like activity, where we “wire in” and the computer and our bodies become one. We have a pride in complexity, and through the grad programme, I’m starting to understand why. Unfortunately it doesn’t make it easy to enter into our industry.
Instead of just sitting back and complaining about the lack of software developers, REA has decided to step up and do something about it.
I joined REA’s Consumer & Brand Delivery Engineering team 8 months ago, it’s been a blast and I love working on the tech we use. We extensively use Docker, AWS, and Ruby to produce internal tools such as `shipper` that other teams use to ship their containerized applications.
We host our own Docker Registry, and we maintain a set of base images, such as `ubuntu-ruby2.2` which is an image based on the official Ubuntu, with Ruby 2.2 and a few other dependencies baked in. We want the teams at REA to use those images, because we control how they are built and we include libraries and dependencies widely used in the company. Continue reading
In June 2015, REA Group Senior Developer Daniel Heath came across an internal ad outlining a secondment opportunity: ‘Need food, shelter and a software developer – please help.’ The role was looking for a passionate software developer to help work on a national initiative with a real social impact. He decided to throw his hat in the ring and was the successful applicant for the role. Continue reading
We’re big fans of continuous deployment here at REA. Merging a pull request and seeing the changes flow all the way to production in a matter of minutes is really awesome. Unfortunately, even with a large number of automated tests, this also makes it possible for an uncaught bug to flow all the way through as well.
We recently experienced this when some new cache-busting code was mistakenly committed and caused our landing page to use a non-existent CSS file. Fortunately we noticed quickly and so the user impact was minimal, but it highlighted that the tests in our deployment pipeline were not as effective as we would like them to be. Continue reading