Get notified about Kevlin Henney

Sign up to a email when Kevlin Henney publishes a new video

[Music]
right so I'm it so where's architecture
begin for me architecture ultimately
begins and ends in the code because
that's the thing that is ultimately real
and a lot of people tend to consider
code to be a detail the problem is that
that is exactly what software is
software is lots and lots of details all
put together in a particular way it's
not-it's not hand-waving we might do
that in meetings we might do that at
whiteboards it might help us think
sometimes it might prevent us from
thinking but ultimately it comes out in
the detail that's where it actually
happens and so I'm not so I have this
kind of issue here is that I'm in the
security track and you know apart from
feeling reasonably secure within myself
that's about as far as security goes for
me I don't that's not an area of
specialization but one thing that is
specialized or rather an area of
interest in which eyes do specialize is
coding practice coding quality how that
builds up to be the larger thing and it
turns out there is a surprising overlap
between these two areas if you want to
reduce the attack surface area of your
software it's no good just looking in
one direction and saying we've got it
covered by frameworks or these guys have
got our back we're using the right
operating system it's a full 360 and I
want to cover one aspect of that which
is often neglected so my background and
I care deeply about the code and edited
this book a few years ago and I also
care about the bigger picture so I've
got a couple of books there with word
software architecture in the title which
immediately qualifies me to talk about
this I believe that's all you need but
there's something else I'm known for a
few years ago I started taking
photographs of software failures in
public places and this is everything
this is 2000 and
six 2006 at Madrid Airport terminal 1
and this is quite a visible failure I
think it's fair to say there's lots of
people wandering through kind of looking
at that and you can kind of spot the
sort of the more nerdy people whenever
this kind of things happen because they
kind of slow down and try and work out
what operating system is about what
works turns out I'd misidentified this
for years and somebody correctly pointed
out but this was actually a 16-bit
networking stack but they misidentified
as as Windows I tracked it down further
this is DOS this is a DOS message from a
particular networking stack this is DOS
in 2006 ok dos had been dead we were it
was the it has been dead so long that we
now think the do S stands for denial of
service and that's what you're getting
here ok this is a huge was this is a
huge error message I mean Saturday took
two photographs yeah it's just like can
I remember it very vividly because my
second my second child he was only he
was only a few months old and it's
pretty much I threw him rugby style to
my wife to catch whilst I got out my
camera to take a photograph of that
because everybody else is wondering whoa
look free packets that's what people
tune into the word free suddenly
everything is good because it's free
anyway I got I got reasonably well now I
started doing this sometimes in between
talks of something and I also take
screenshots so given that we're going
back a few years for some of some of you
this may be a fond memory yeah you can
tell how old it is because I'm still
using Mozilla you know and I was I used
the I remember I was trying to see a
friend of mine visit him in diving
direct and I wanted an earlier train
apparently there are no earlier trains
there are there is only java.lang got a
nullpointerexception
and I use this at a conference in in
Amsterdam a couple of years after I had
this I took this image and somebody came
up to me afterwards and he said
Kaplan you know they still have that bug
on the site and this is this is this is
kind of where the penny dropped where I
started realizing that we in failure we
learn a great deal about a system we
don't simply learn about it's technology
the underlying technology we if you
hadn't guessed it was Java because
somebody has decided to plaster the
technology all over the URL why say it's
a service why do people put ASP JSP PHP
etc in their URLs
did they not learn about encapsulation
okay nothing says nothing says
encapsulation like a stack trace okay
hello this is full stack development
this is a Hilton website as she goes on
for you about there if you want to know
what they're using on this site yeah
fine if you want to find out the
vulnerabilities there's a software
checklist there but this is the other
thing you're learning about you're
learning about how oh how did a simple
how did a simple error like this get
through shouldn't there be a big try
catch that basically says nothing
nothing raw gets out of here okay if
something bad happens we tell we tell
the user we present them with a message
and we say you know what I'm sorry
things didn't work out and we do that in
English or we do that in Dutch but we
don't do it in Java okay there's an idea
so how how could this obvious thing I
mean it's a really obvious thing is
practically mental check this check that
no exceptions propagate across this
boundary so what about the boundaries
always about the boundaries so so what
what happened now I can't tell you what
happened but we can throw out some
theories so maybe the developers were
not aware of this perhaps they were new
to Java
perhaps they were hurried perhaps they
were against deadlines perhaps they were
rushed perhaps this code was checked in
under pressure from management perhaps
this is all out sourced and nobody
actually cared because it wasn't their
interest the fact that it took over two
years for them to fix this in fact they
actually rewrote the site and the next
time I checked what does that tell you
about the management and the
organization around it in other words in
failure we actually reveal a profound
something much more profound about how a
system is built but these days I don't
have to take these photographs anymore
because people send them to me oh thank
you for your object model I can now see
it reveals yeah people just send them to
me
so yeah I've got I've got over a
thousand of these images that people
have sent me and in fact it's got it's
got to the point that somebody recently
coined a phrase for him there apparently
I am I'm nine aim is now been used I
they are Kevin Henny screens and you
know once you've got an adjective then
you know somebody else said oh eh Kevin
Henny apparently there's more than one
of me which is slightly disturbing but
but yeah so there you go so that my name
has come to the point that at the agile
in the City conference in Bristol where
I live last year one of the organizers
John Classen came up to me said Kevin
there's a screen downstairs quick I want
to take a photograph with you pointing
retweet it so we kind of right there you
know would the snake is eating the tail
at this point okay but this is an
interesting thing the question you have
to ask these are all these are all
failures at what different levels in the
system but this is a track on security
and the question I put to you is what is
the difference between a failure and a
failure what is the difference between a
defect in one aspect and a defect in
another because a few weeks ago lots of
people were sending me these from all
over Germany the train system I've got a
couple from the NHS in the UK these
ransomware this is the wanna cry malware
this is so there's a question what is
the difference between one of these and
there's a thing they can no longer do it
happened there last year in San
Francisco and a lot of people got free
rides for a few days because of
ransomware ok the whole thing was taken
down and some of these are based on
spear phishing attacks and therefore the
human element but ultimately there's the
idea that if you can just drive a wedge
somewhere in a
you know anything about its
vulnerabilities and this particular case
this is to do with not having the right
versions of the software as in running
things like XP which are definitely past
their sell-by date but the point there
is that these vulnerabilities exist and
they exist at all levels from within the
code all the way out of the human level
now we're not going to deal with
directly with the human level but I want
to make the point here that the user
experience of these from a user's point
of view these are almost equivalent user
experience and the security experience
which I quite like it we make that sex
that's good that's you know it's much
Ochs come on come what kind of is that
security experience sex yeah but I want
to talk about something else because
whereas some of this come from this
comes from the programmer experience
what is it like to be in the code
because people are not generally one of
the things I've discovered is that
people in software development are
generally not stupid or malicious okay
but they are often in a hurry they are
often confused by multiple priorities
there is so much to know that you cannot
know it all and so there is this idea
that we need a decent environment in
which to work what is the programmer
experience we often talk about the
architecture of a space as just meaning
structure but from my point of view an
architecture is not simply a structural
arrangement it defines the quality of
living or working in a particular place
what is the quality of being in that
code what is the quality of working
within that environment you know if
you're spending eight hours a day in
there what does that feel like is it
comfortable do you enjoy going in there
or do you feel that you know maybe you
need to put on armor okay it's an it's
another day 10,000 line class it's me
versus the class you know what's it
going to be there are no tests right
your will before you go in so this is
whole idea what's the program experience
and we see that this affects things this
is where the details matter because and
this is also where we find equivalence
so 2014 there were two SSL bugs which
arose from very simple coding situations
go to fail and heartbleed yes here's an
extract
I've taken this strong and refer to my
clans article a bit later but here's an
extract of the go-to fail thing now we
can have various debates about the
merits or demerits of the go-to but this
isn't this comes from a much larger
context it is not immediately obvious
that it is correct and it is not obvious
this is one detail that one line that is
a detail
remember those details people say oh
don't worry about it's just a detail it
turns out is the difference between a
system that works and a system that does
not a system that has vulnerabilities so
all architecture is founded on the
details ultimately it comes down to the
quality of your mortar the quality of
your screws it has to be consistent all
the way through therefore coding
practice is important notice that
there's almost no difference between
that and this recreation of the AT&T bug
in 1990 which basically knocked out the
telephone network for about 150 million
subscribers in North America on a
weekday back in an era when people
actually use telephones as telephony
devices so that's a lot of business and
this this comes down because the
programmer wasn't really thinking
straight and just had a kind of doll
I'll just put a break in here this is
this is equivalent to a denial of
service attack this is the point these
things happen they reveal
vulnerabilities they deny people our
access to things they give us a very
poor user experience so this idea in a
quote local boy Dijkstra most of our
systems are much more complicated than
can be considered healthy and are too
messy and chaotic to be used in comfort
and confidence and this is true of the
outside but it is also true of the
inside it's what's going on inside the
system that we have to care about here
so let's have a little bit of a look at
structure and do we know anything it
turns out we actually know an awful lot
sir quote from GERD Holtzman who he's
one of the chief architects for chief
designers and developers at NASA's JPL
laboratory and he headed up the software
development for
the Mars Curiosity rover which is one of
existence and wrote this wonderful piece
for communications of the ACM a couple
of years ago Mars code and you can get
an only one free read I strongly
recommend this one at that site there
are standard precautions that can help
reduce risk in complex software systems
and he lists them this includes the
definition of a good software
architecture based on a clean separation
of concerns data hiding modularity
well-defined interfaces install a strong
fault protection mechanisms that last
one is clearly very context-specific
you need fault protection mechanisms if
you're going to put a probe on another
planet because it turns out if it goes
down you can't easily just oh okay just
send something into the server room and
hit the button if we could send some
buddies to the server room and do that
we have people on Mars but that's not
going to happen right now so that last
one is very context-specific but look at
the previous ones separation of concerns
data hiding modularity well-defined
interfaces these terms are so old that
practically hanging out with the
dinosaur bones okay these are not new
concepts and he's doing this because
he's saying well this is how you make
stuff comprehensible this is how a human
being can understand something how on
earth you supposed to say that a system
is you know secure how are you supposed
to say that it is robust how are you
supposed to say all these things unless
you can actually reason about it and
tackle it on its own terms so I have
another interest amongst many I mean
obviously I like taking photographs of
books and I run a page on what on
Facebook called word Friday and word
Friday every Friday I have to name
suggest I put up a definition of an
unusual word and the rest of the week I
just focus on linguistics and other
vocabulary and so it's all good fun but
given that I do like a I actually like
dictionaries just for their own sake I
thought I would go and look at the
dictionary for the words that I've used
in my title code as risk I'm going to
say that as is easy enough let's just
focus on code for a moment code a set of
instructions for a computer hopefully we
are all comfortable with this I know
it's straight after lunch but hopefully
we're all
with this a computer program or a
portion they're off yet this will make
sense a system of words figures or
symbols used to represent others
especially for the purposes of secrecy
ah yes it turns out that many people who
write code write code you know you kind
of looking at it go like Kevin you're
looking it upside down oh you're right
yeah I couldn't quite tell if it was odd
furred no no no it's not obfuscated that
just my natural style so the point there
is we want to we won't understand
meaning we won't understand intent we
want to be able to we want our code
quite literally to be reasonable to be
able to reason about it the classic
sense of the word but there's another
meaning of the word code which i think
is interesting here a set of conventions
or principles governing behavior or
activity in a particular domain a code
of conduct for example the set of
practices which a developer will arrive
at the code and collaborate with team
members that is the code as it were okay
so let's look at risk now risk is often
often misunderstood a lot of people say
Oh risk is uncertainty or risk is hazard
or it's danger it's not it's a very it's
a very as much I'm specifically defined
so we go around and dig around we find a
situation involving exposure to danger
and these are two elements we're going
to see running through this the chance
or hazard of commercial loss a very
specific one that is used in the
insurance industry product of the
consequence and probability of a
hazardous event or phenomenon ah now
this is interesting because actually
here it takes it takes the basic idea
that we can see exposure to a
proposition of which one is uncertain
it's not about uncertainty it's about
exposure to uncertainty it's a very
subtle distinction if you put yourself
in harm's way then that's clearly going
to be a worse proposition than keeping
yourself out of harm's way and so there
is this idea of exposure to uncertainty
risk is something we can do something
about in other words we can reduce
exposure we can reduce uncertainty by
doing a number of different things and
it turns out very few of these things on
you
but also there's a mindset change coke
pepperdine a few years ago tweeted this
one at me functionality is an asset code
is a liability
however thinking this is really
interesting because I've spent the
better part of my career trying to
convince people that code is an asset it
turns out that these are both
simultaneously true but they offer us
different perspectives the idea is that
what people want is functionality when
you download a new framework that's what
might be able to see the source code
that's great but normally what you want
is the functionality you also want
confidence in the functionality in other
words you want a system around it that
system is a system of people a community
a sense that other people have used this
software and have you done so reliably
you want the sense of activity that the
system is alive rather than dead if the
last check-in was five years ago
then perhaps don't touch ok you want
that kind of responsiveness and
reactivity you want to sense beyond you
want the system beyond the system so to
speak you're looking for something very
specific that becomes the asset as well
but why is the catalyzer code the
liability well I want you to imagine a
change to the current system you're
working on ok done good that was easy
what is preventing you from doing it
from applying a change it turns out is
the code the code is the thing that
prevents you from changing the code now
why is this a useful construct well it
turns out that what companies do when
they recognize they have liabilities if
you have a financial liability you watch
it like a hawk you make sure you
minimize your but it's not about
elimination of liabilities there are
very few companies that have zero
liability what they're trying to do is
understand the balance they're
understanding the trade-off they don't
want to have their liabilities run out
of control and wipe out their assets so
that's what you do that's why code as a
liability is actually quite a useful
construct because it means you watch it
like a hawk you make sure you have less
of it rather than more of it you make
sure that you can understand it so when
somebody says I have no idea what's
going on in this subsystem but it seems
to work seems is not good enough
the fact that you had no idea that's a
liability you have no you are exposing
yourself to risk and you have no idea
there's uncertainty in there you don't
want to be in that position so the idea
that it's a liability is really useful
way of thinking about it you want to
minimize it you want it to be exactly
what you want you don't want dead code
you don't want incomprehensible code you
want to be able to understand it and
that everything there is a necessary
part so that when things change because
it turns out that's one of the most
popular things to ever happen to a piece
of software but humans are very bad at
recognizing this we use words like done
we've even elaborated it we've even
raised it to the power I even hear
people going dun dun dun as if that will
somehow assert that it really is done a
system is only done when nobody's using
it it's abandoned at that point okay so
you need to be able to create an
environment a situation in which you can
change stuff it's pretty simple
observation complexity complexity
introduces bugs so therefore avoid it
where possible and this is the our
aspect it reduces vulnerabilities if you
avoid complexity you produces
vulnerabilities so what do we only talk
about when we're talking about code
complexity and things like technical
debt and so on we only talk about
refactoring but I want to introduce you
to very simple very simple kind of
right-hand rule about how you reason
about the changes in your code because
when we talk about the properties of our
code and when we use the language of
requirements we're not very good we have
this very poor vocabulary when we talk
about the semantics of a system when we
talk about its behaviors and
interactions its general correctness we
talk about functional requirements and
then you ask people okay so what about
the other requirements and you're stuck
for a word and you go non-functional
because they're so important we don't
even have a word for them and you're
saying what are those requirements
they're the ones that aren't those you
know we're human beings each natural
language that humans have has a vast
vocabulary to draw on and the best we
can do in English which has trolled
pretty much
ransacked every other language on the
planet for its own vocabulary the best
we can come up with is non-functional
the default meaning of non-functional
English by the way does not work okay if
your washing machine is non-functional
that is not a good thing we're not
talking about availability or rather we
are we're talking about two completely
lack of availability there is not a
proper word called non-functional you
need to give it it but the other thing
we do is we collude we combine and
accidentally create a category that
doesn't exist there are three categories
or we can split these further but there
are three essential categories that will
help us focus
there's the functional stuff there's the
operational stuff the executional stuff
that's the how does it run what are its
resources what about time what about
these other illa T's that people talk
about the manifests themselves at
runtime and then now are the
developmental qualities of a system its
maintainability its testability
these are development books they see the
top two are experienced at runtime the
bottom the bottom category is
experienced by developers now these are
not perfectly orthogonal but then again
neither my fingers so I'm not worried
about that but it is a useful thinking
structure because what it means is when
we are refactoring what you're doing
you're refactoring is you're trying to
hold the functional axis still and
you're trying to improve something about
the developmental axis you're trying to
say I want this to be more readable I
want this to be simpler I wanted to use
a more recent version of the language or
libraries you'll try to change something
on this so one remains fixed and one you
go to improve but the operational axis
is open it's a wild card it can go
either way it can get faster or slower
they become more or less secure it can
become more greedy for memory or
actually more streamlined in memory in
other words that's not the one we're
concentrating on there's another
function out to prefer preserving
transformation that's the other way
around
which is we focus on functionality we
focus on improving some aspect of the
operational side with such as
performance tuning and the developmental
aspect is open maybe the code gets
Messier maybe it gets better so with
that in mind let's just take a piece of
code and refactor it and this is a piece
of code I was quite a kind of
interesting because I was going
some code and then discover that she had
a piece of code lying around another
talk which I just tweaked a little bit
and that's actually based on something
from one of my clients and I've rounded
it and changed everything to protect the
innocent and the guilty but it's a piece
of C++ code and we might say well the
first part of security is don't use C++
yeah you know if you're a JavaScript
programmer you just tell yourself that
all right languages do expose themselves
more or less to this and certainly raw
languages that have a raw memory model
like C and C++ that does increase your
liability but all the things I'm going
to look at here are related to you can
apply in other languages so here's a
piece of code which obviously you can
see at the back yes good and what I want
to do is I want to go through this piece
of code and simplify because the
original goal of this was actually
simplification and then I realized that
half of what I was talking about
actually has that fits directly with the
message of what we're talking about here
we are reducing the idea of code as risk
so first of all I'm going to give you a
quick tour just run through this just to
get a sense of what are all the things
that are potentially reveal some kind of
vulnerability or involved in some kind
of vulnerability there you go so those
are your red-green color blind like me
that's half the lines so wow let's go
have a quick look at these guys sort of
we got we've got a bunch of declarations
helpfully called declarations just so
you know and we've got some information
about getting some config and we get
some more config and then we get some
more config and we do things so much
code is imperative it's all about the
doing and then finally we actually do
something meaningful we do a conversion
and then we do some more we do some
checking and finally we return somebody
a result okay so let's go back to this
the first thing I'm going to notice is
all of these wretched comments okay what
is the thing you're going to do with
lots of sections that are commented huh
methods you can factor no you're going
to correct the spelling mistakes
right now check it in now delete them
okay okay I did say I'm into words and
language you know I'm going to check
those spelling mistakes they've really
bugged me okay now now you've got a
version that's got the correct version
of the comments should anybody want to
roll back to this okay then we get rid
of them okay let's go through piece by
piece there's all these declarations up
at the top and see was a block
structured language still is a block
put variables in blocks a lot of people
are not aware of this and I remember
saying this to a colleague and he said
oh that's just your crazy C++ stuff you
can move that you can move that you know
I said no no really it's it's C you can
actually look in knr they've got
examples there so well how long has that
been in C language
I don't know 1971-72 Oh so let's
redistribute the variables so that we
reduce the distance we increase the
awareness that we have humans are really
good at chunking so it's play to our
strengths instead of playing to our
weaknesses we're very poor when things
are fragmented we cannot reason about
them so let's allow somebody to reason
confidently about the code let's move
things to where they need to be so we'll
do that okay that's the first step and
the next thing I'm going to do is Ivan
this code was originally old C++ but
it's been compiled using a C++ 11
compiler and C++ 11 there's about as
much resemblance to classic C as perhaps
modern English does to anglo-saxon it's
yeah you can kind of compile it but
really there's an awful lot more there
so let's just tidy a few things up I'm
going to tidy up some declarations and
we'll continue doing that let's just
focus in we've got some stuff going on
here
look at that going on well what's with
the issue here yeah it turns out you're
never going to get a null pointer in
these cases this is just noisy code it
prevents people from actually seeing the
condition there is no situation in which
a null will be returned so therefore we
get rid of that okay we might want to be
memory safe so sometimes people try and
use a smart pointer problem is that this
is a C++ 98 smart pointer so we're using
older versions so this is a very
important generalised observation is
that the you
you actually care when people say I want
to upgrade stuff when people say I want
using deprecated features they have a
very strong case in their favorites not
just because they want to try new shiny
things but I'm just going to refer you
back to the idea that older code older
libraries is more likely to be error
prone and more likely to have
vulnerabilities so therefore there is a
very good reason to stay up to date with
stuff Auto pointer is deprecated so we
shouldn't use that we should use unique
pointer however this is too early in the
process to change the signature of the
method so I'm going to move that one out
and we're just going to keep it private
signature and I'm going to change the
statically typed language you have lots
of excitement in breaking things so
let's not do that just yet okay now the
next thing the next thing is some a
little more interesting the next thing
is I'm going to focus on these things
instance you've got these little like
getting using a using a language like
C++ using a language that actually does
have a few high-level bits and pieces
and then completely ignoring them we
generally call this C+ okay so we're
going to use strings except we're not
really going to use strings we're going
to use strings and then we going to go
inside them and we're going to go yeah
I'm just going to get that pointer out
of you I know you said you were a nice
string object but I really want your raw
char pointers I want to see that null
you know it's just like this is this is
keyhole surgery with a sledgehammer now
the problem is that curiously enough
this works by coincidence there's a data
function data doesn't guarantee its null
terminated which is something that C has
a very strong opinion about if
something's not null terminated you get
lots of exciting possibilities for oh
that's it buffer overflow one of them
still one of the world's most popular
forms of attack it turns out that c++
11th i did this one up but it also told
us way back when you if you want the
underlying c string you can ask politely
you can manifest your intention and say
I want the C straight I don't merely
want your data data is a terrible name
anyway for anything
Peter Hilton and space in the
Netherlands he did a study on variable
names most popular variable name
longer than one character turns out to
be data either github server turns out
the second most popular is data too so
okay that's a very minor one but let's
move on to another area which is there's
all these things sprinters if you want
vulnerability its spelt printf a lot of
people aren't just formatting a string
printf is an interpreter it is a
language it is not far removed from
basically saying I wish to evaluate
content please I invite your I invite
your injection attacks I invite
cross-site scripting all of Esther this
is the gateway this is the gateway and
everything else in other languages that
has an Evo or any kind of interpreter
you need to recognize that whenever
you're using something like printf it is
a whole language and it allows all kinds
of exciting things so it is at one level
equivalent to a very modest form of eval
and that's not something you really want
it's conveniently spelled close to this
yeah the classic example of an injection
attack is beautifully covered in this
xkcd hi this is your son score we're
having some computer trouble oh dear did
he break something in a way did you
really named your son Robert etc etc
oh yes it'll Bobby tables we call him
well we've lost this year's student
records I hope you're happy and I hope
you've learnt to sanitize your database
inputs this is a point I Oh remember I
said earlier on boundaries that's what
you need to guard it's all about the
boundaries it actually doesn't really
matter if there's C++ in the core of
your application it's the stuff that's
at the edge you need to worry about and
it doesn't all look like memory memory
based languages it turns out that you
can quite happily have interpreted
languages softer languages any language
that allows you to embed content within
something else immediately opens up
these possibilities the simple way of
looking at these are all about escape
codes as I've observed in the past every
escape as an entrance okay that's the
way you need to think about this stuff
you need to guard this very very
strongly so we can get rid of that and
say no that's printf should not be there
I can use a more valid secure
TV version SN printf but actually this
is C++ I can simplify it even further I
can actually look at the content
realized we shouldn't be formatting
strings anyway for this kind of thing
these are almost always constant and
progressively the code reduces well the
next thing I might do is notice this
terrible habit is terrible but popular
habit of I've got an error so I'm going
to log it and throw log and throw log
and throw if you ask some people what
does your system do well mostly it logs
and throws does it do anything else yeah
we've got some stuff in there about
insurance you know or maybe it's a games
platform but mostly it logs and throws
if you look at some code bases that's
what they seem to do they seem to be
dominated by this stuff so in theory I
could reduce that but what I'm going to
do is I'm going to pass it away and say
you know what I'm not interested in that
I'm just going to say failed to connect
we'll come back and deal with that later
well maybe not and because I like my
code to be less noisy there's an awful
lot of open close curly bracket there we
can get rid of that and reduce that to
one line which song has some people
exclude can you do that yes you can and
you're perfectly entitled to isn't that
the basis of the go-to fail ah well I'm
going to introduce you to a really cool
idea it's called a static analysis tool
it's an extension of your compiler if
you're working in a dynamically typed
language you need one of these
okay as well in other words the idea is
don't just go with what the compiler
says extend your reach so we can zoom in
now and we can notice this kind of
beautiful gentle repetition this kind of
lulls you to sleep let's pick on
something else let's pick on the
signature at this point I'm comfortable
making a change I'm also going to move
away from this wretched I bet I guess I
call it object-oriented assembler this
rather there's terrible debasing of
language where people walk around and
they're only vocabulary is create and
get and set and all of these kinds of
primitive words nobody ever wants to
create a server connection or rather
we've created a server connection we've
got a new expression you don't want to
create a server connection what you want
to do is connect to a server okay yeah
picture code at the right level stop
describing the assembly
version of your code communicate this is
what it takes to connect to a server
offer the reader the right level of
abstraction communicate with them it's
an act of communication if you
communicate to your reader they will
listen they will learn this is about
knowledge it's about the ability to
reason then we got to go inside ok
configure my configuration manager :
code on incidents get values ok well
let's let's try to turn this into
English configuration manager instance
get value no configuration manager
instance value of configure Hall we
don't need the manager word there who
knew you know it's just like people kind
of pad out their words oh yeah here's
the thing can you call it a thing no I
need to call it a thing controller
manager proxy yeah but that's not the
real one oh the abstract thing control
about your proxy yeah do we have a
factory for that yes we do and that
guess what it's called no no no no no
stop it's a thing call it what it is now
there is still a problem with this now a
lot of people think oh oh Kevin's going
to talk about Singleton's yes he is
there you go when we're done and because
there's another problem here yes it is a
whiskey yes it is better for your code
okay that's all you need to know yeah so
there was a paper published last year
using it as using its conference early
detection of configuration errors to
reduce failure damage if you notice
we've just been using all of that we
haven't actually done much validation
what we did in that code was check
whether or not the data was empty that
was it it turns out that studying across
a number of systems and applying a
particular tool which is not the focus
of this talk I'll study shows that many
systems are subject to latent
configuration errors in their critically
important configurations those related
to reliability and all the rest of her
latent configuration error that's a
polite way of saying we didn't check it
when we ran ok we we got it at first
point of use something bad happens how
often well across there's quite a wide
range some systems it's over 90% of
these configurations do not have
special code for checking the
correctness of their settings at the
system's initialization time that
settings about everything that settings
about who is using the system that is
settings all about how the system runs
and these are not checked now this can
give you exciting runtime errors but it
also opens and reveals and enlarges and
attack surface area so the first thing
we're going to do is we're going to
observe that this is not a singleton
issue it's not the job of this function
to know how to validate these two
configuration aspects it's the job of
whoever calls it so we move that up
for that because this code turns outs
repeated all over the place whoever
gives you the data in fact it turns out
there's another aspect and this is where
I'm going to go against one of the
classic observations from john postal
you've made it into the one of the early
RFC s for tcp postal is law we often use
as a way of describing general you know
acceptability or tolerance code be
conservative in what you do be liberal
in what you accept from others actually
I think that that's too general
we conserved in what you do but be
conservative in what you accept from
others actually it is your the job of
your code to be as hardline as possible
and this this applies both in the large
certain things don't connect then that's
fine now that gives you better long-term
compatibility as people shift standards
but it also turns out to be irrelevant
in the context of your code why am i
accepting strings address is not a
straight n address is not a string a
port is not a string we already have
types for those from the friend standard
c library so I'm not changing the
language here but I'm actually showing
you this is what you can do if you
actually use the language now you may
notice that we've managed to reduce a
surprising amount of code I've changed
font size I could change it again and
actually fill up the screen and then we
look a little more closely because it
turns out that it's not the job of an
object if a drive an object cannot be
created correctly don't have a
conversation with it are you okay yes
they're okay for you are we good no it's
a job as the construction of the object
if you cannot create
a valid instance then you do not have a
valid instance it's as simple as that
for profound and very simple existential
concept so therefore it should fail on
creation which allows us this which you
know what actually we don't need any of
this code at all it turns out it's one
of my favorite refactoring exercises at
this point this could be any language
because it turns out it's the same idea
we have certain habits all of those
things that we say a bad code poor code
and so on they're not created randomly
they're created through certain
systematic habits and that was one of
the things that my client had they had
late binding a configuration through a
singleton habit they had a number of
these things and if you write code like
that you can turn hello world into an
enterprise masterpiece okay
it's a sick it people don't create code
randomly it's a systematic approach so
observations from this first observation
there is no code faster no code have
some intelligent guide to designing
programs there is no code more secure
than no code it's really difficult to
hack something what it isn't there and
that's one of the key things you wanna
reduce the surface area reduce the
volume then we have other things and go
well that's fine we're using javascript
so about a year ago it turns out that a
lot of people depended on a few lines of
code and for various reasons that were
I'm not going to go into here the author
of that code pulled pull this code from
NPM and large parts the internet stopped
working so let's have a look at this
code that is really important now if you
have open source code I salute you it's
a great contribution and that's that's
wonderful but that doesn't necessarily
mean it's good one of the other things
about open source is gather other
people's opinions see what they say get
their feedback but to be honest here
this is not necessarily the greatest
code but it does something very trivial
it pans out a string it turns out lots
of people were including this just to
pan out a string I'm I'm going to I'm
going to suggest that this is not one of
those really hard problems
this is this is something perhaps that
we should be able to do when this is
pulled somebody went and replaced it
with this which actually is more complex
and shows some slightly deeper
misunderstandings of code which makes me
a sight
Anson's law I have yet to see any
problem however complicated which when
you looked in the right way did not
become still more complicated we need to
be moving the opposite direction but
that's not why I'm that's not why I'm
here because there wasn't really a
security issue there or was there
because let's be serious we are taking
on dependencies we're taking on needless
dependencies if you're not seeing the oh
really
series of joke titles these are
wonderful because code written by some
stranger on the internet is always
perfect so people are just depending on
stuff and they are depending on stuff I
have no problem with you depending on
stuff if you know that you're depending
on it the problem is a lot of people did
not know that there was a transitive
dependency they did not know that this
was sitting beneath what they had chosen
and dependencies are part of your
architecture so when somebody goes ahead
and does this this was a this is
unprecedented and there was a lot of
discussion about this hey NPM users left
pads in it was unpublished breaking lots
of bills to fix we are undone publishing
it at the request of the new owner so
hang on there's a lot of websites out
there that are just taking on trust a
piece of code and now somebody is able
to just upload an alternative version
now what if the original developer
decided to do that and instead of having
this then replaced it with something
with a little bit of fun so let's be
very serious here when you have a
dependency on something else and you
wander around going our systems secure
then one of these statements is not
correct you need to guard your
boundaries this is when we look when we
talk about architecture one of the
definition is the Grady Booch officers
on architecture architectural decisions
tend to concentrate on PI identifying
controlling the scenes in a system which
are described in terms of interfaces and
mechanism now normally we think purely
in terms of the abstractions of the
language but whenever you introduce a
process boundary your dll boundary a jar
boundary or any of these boundaries
you're saying something significant
about who gets to touch and deploy these
things these are one of the simplest
ways of you know revealing an insecurity
in system and just spoofing in not
spoofing cleverly on the wire but just
somebody's user ID because it turns out
that yes indeed people are sometimes the
weakest link if you can get one of the
developers you can get their login then
you can do all kinds of stuff so it's a
very simple idea do you know your
dependencies and what is the criticality
of those things so Maya layman it's
wonderful observation it's around 1980
said as mankind realized more and more
on the software that controls the
computers that in turn going society
becomes crucial that people control
absolutely the programs and processes by
which they are produced throughout the
useful life of the program and that's a
point here are you controlling
dependencies when you say we'll use that
library to what extent are you
controlling that dependency have you
safeguarded that what do you thought
about it what if what happens if that's
taken away it's a very good question
what are the consequences of it's taken
away if the consequences are minimal
then that's fine but you need to
evaluate that before coming to their
conclusion but what about the processes
so I'm going to go back to something I
mentioned throughout the beginning mike
Bland's piece really it's a long read
hosted it it's an essay many parts
fail heartbleed in the unit testing
culture and he made some really
important points here and he explores
all of these details as he says these
bugs are as instructive as they are as
they were devastating they were rooted
in the same programmer optimism
overconfidence and haste that strike
projects of all sizes and domains these
bugs arouse my passion because I've seen
and lived the benefits the unit testing
so he's thinking from these points of
view let me just go back to that left
pad example there was this and there was
this I ended up having a go doing this
and replaced it slightly more recent
version of JavaScript so there's an
extra there's one line less there but I
can tell you that this is not
functionally equivalent to these two now
surely when you replace something it
should be functional equivalence
well how do I know this and what are the
differences well I wrote a very simple
test set of tests you know you can put
it on two slides including the framework
this is what happens when you run the
tests this is the screen you get when
you run the tests against my code for
left pad this is the screen you get and
red means bad when you run it against
the other tooth it turns out not only
but people using it wasn't a security
vulnerability but actually didn't quite
do the correct thing so it was actually
wrong this is the whole thing you need
to trust these things this is why we
have observations like this one from
Neal Ford testing is the engineering
rigor of software development it's very
much that idea of something that gives a
sense of reality and strength to what
you're working on I'm going to let them
go first because I'm polite but I'm
going to I want to close by considering
when we look at testing what is the role
of testing here well I've lost focus how
do you test let me just introduce you to
three different ways of thinking there's
a passive approach which we can call
plain old unit testing counting that's
you write the code you test after ok not
too long after but you test after you've
got an active approach which is where
the code doesn't really exist you you
actively create the code and the tests
alongside better known as test-driven
development but one that Mike bland uses
it in an article extensively was
something we might call DDT defects
driven testing the idea that in response
to an observation either external or a
bugs that you have found there is an
insecurity or just a user annoyance you
are in a position to write a test that
catches that and demonstrate your system
does not have this vulnerability does
not have this weakness it's a very
simple idea and that's a much richer
idea because there's this other paper
from use Nick observes simple testing
can prevent most critical failures how
much turns out on a particular system
they were looking at specifically the
non-fatal are the fatal errors they were
looking at
it was around 77% of production both
could be reproduced by a unit test so
that's three quarters now for some
people that's astonishingly high for
some people it's starching Leeloo
however it's a number it's a number you
can do something with it's a number
you're never going to reach in advance
necessarily but retrospectively you can
there is this idea that this is not done
it's always an ongoing process so is
there anything well I'm going to leave
this one for the slides it turns out the
cert guide you know top ten well top
twelve secure coding practices over half
of them are to do with code quality and
basic testing so this idea that these
are not optional extras sometimes
they'll yeah we'll deal with the code
college next year this year we want to
make our code secure we want to make our
system secure but we're not going to
touch the code to do that it's like no
this is one of the this is one of the
surfaces that you need to address
because you want your system to have the
classic qualities of an architecture
these are the qualities that the Roman
architect Vitruvius observed of a good
building it should be firm it should be
robust it should be strong it should be
resilient it should be useful it should
serve a purpose and it should work for
that purpose and then if des Venus the
goddess of beauty you should also have
some aesthetic it should also be
something that as a human being I can
appreciate and as a human being in the
code I want to be able to appreciate it
on those terms thank you very much