Practices of Agile Security

In my last post I talked about why principles matter and how we need to move past top lists and 58 point security “checkups”.  This leads to a functional problem: I haven’t found anything in regard to security that I believe “gets it”.  Instead, we are forced to look elsewhere for answers.  Luckily, it’s not a far leap

A brief history of the agile movement

A few years ago a some guys got together to try and figure out a better way to develop software and to help others do it.  In that effort they released a manifesto which presents their core values of what they believe to be the way forward.

I am repeating it here for those who haven’t read it:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

These value statements are supported by twelve distinct principles which directly help guide development.  These are:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

So what?

While the list above may, on the surface, seem contrary to my pointing out the fundamental flaws in lists… these lists above are different.  The difference is that the above are statements regarding value and principle on how to write better software.  They aren’t trying to pimp a silver bullet, they aren’t trying to scare you about diseases you should try not to get, they aren’t giving you a TODO list you are going to go take home and forget about.  Instead, you have are left with a concrete foundation to build on and a measuring stick to help along the way.  They are very open ended, forcing you to find solutions for yourself.  Also, if you recall my last post, you may notice that you are still not presented with any actual “meat” on how to actually achieve the above.  What are the characteristics and practices that embody the above?  Luckily, there is in fact a manual.

Shortly after this was presented, a book was put out called the “Practices of an Agile Developer“.  This book really resonates with me and I have read it a few times since because it’s a timeless read.  This book focuses on the characteristics and behaviors that help support goals and principles listed above.  The whole book is composed of little development concepts and nuggets that are language agnostic and rich with value.  The important thing to note here is that this book is designed with a focused intent.  It’s not just a collection of incoherent thoughts scrapped together by a smart guy.

As a quick aside, this book also goes hand and hand with a book called “The Pragmatic Programmer“.  That book is, par none, my favorite book on programming.  I read this book every single year once a year and am STILL learning things out of it.  It is formed and focused in almost the same fashion as the aforementioned book.  It is the foundation of what I believe compromises quality and professional development.


In order to write better software you have to know what you value and prioritize it.  With out that, you can’t discern any principle as to how to get there!  Principles support those goals and gives you an operational foundation you can use to measure your progress.  Lastly, characteristics and practices gives you some concrete tools you can work with and take ownership on.  They let you take ownership of all of the above such that you can progress as a developer.  (and they do so in a fashion that doesn’t require you to know the principles OR values!)  The books listed are manuals based on the goals and principles that these developers truly believe will make for great software and successful projects.  Simply put, they outline a plan and strategy on what they believe makes you a more successful and better professional developer. Also note that the above goals and principles have spawned lots of different approaches that embody them!  That is one of the coolest pieces of it!

Why doesn’t something like THAT exist for security professionals?  The short answer (as far as I can tell) is because there is more money in scaring you and selling you a solution.  I hope I am just looking in the wrong place or something.

Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: