Security, it’s time to dance with the DevOps

Security are the next people in mainstream IT organisations (horses if you prefer) who need to start writing lots of code.  Many other types of people have already joined the coding party:

  • Developers started it(!),
  • Testers joined (automated testing done properly i.e, not recording mouse clicks),
  • Infrastructure and Networking joined (IaaS and SDN),
  • Middleware teams joined (e.g. Chef, Docker),
  • …and the latter 3 even joined together to build platform applications (PaaS / PaaA).

Only Security teams are still gingerly sipping a drink on the edge of the dance floor and watching the others.  Or perhaps waiting until the end of each song and shouting out complaints about anything making them unhappy.

So dance (code) Security teams… you’ll be fine and the party needs you.

We know Deming wouldn’t be happy with practices such as 11th hour pen testing.

Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “You can not inspect quality into a product.”

There are lots of neat ways Security teams can write code:

  • Build-time checks on 3rd party dependencies e.g. the OWASP Dependency-Check Plugin or Black Duck (even legal departments may want to dance for that)
  • Unit tests
  • Static code analysis focused on security e.g. SonarQube
  • Write runtime security checks (heck even do BDD and use something like Cucumber to capture malicious use cases).
  • Penetration testing during a continuous delivery pipeline e.g. using OWASP ZAPP
  • Many more opportunities I’m sure – feel free to add them as comments to this blog.

I’m not suggesting this idea is new, for example this document was from 2006.  I just still don’t see evidence of enough of it.

So Security teams – if you haven’t already, it’s time to download an IDE!



Apple Music versus Continuous Delivery

Last week my phone received iOS update 8.4.1,  Being into Software Release Management, naturally I read the release note.

On a slight tangent, I’m ashamed to say that when it comes to my phone, I don’t practice Continuous Deployment of app updates – even though I know it’s been possible since iOS 7. Instead, I like to also read those release notes before deploying (it’s not that bad – I don’t raise a Change Request or run a CAB!)

Anyway, the release note explained that the reason for an update was an update to Apple Music (a new music streaming software aimed to challenge Spotify.  At this point my Release Management instincts were offended:

I have to update my whole Operating System in order to update just one application?

And one application I don’t actually use.  (NB I actually don’t use it because I’m tied to Spotify through my phone contact, not because I’ve yet tried and/or rejected Apple Music.)  Even worse, this upgrade caused me downtime on my phone.

So I wonder:

How long Apple will continue to release a monolithic Operating System and Music Application build package?

Or interestingly do they have other reasons for doing this?  (I notice they did bundle security updates.)

Spotify have a standalone application (thanks to the App Store capable of Continuous Deployment of updates – for those so inclined) and they release very regular updates.  I can’t see people being happy with taking iOS Operating System updates as frequently (unless they can start happening without an outage).

In my opinion, whilst this situation continues Spotify have to posses a commercial advantage. Especially with all the great things we see and read about their agile culture.