Code as Risk • Kevlin Henney • GOTO 2017

[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 to it then I'll tweet it then you 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 the other from the user point of view 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 that it is wrong and this is the point 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 the coolest pieces of space hardware in 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 this is we've actually got an equation 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 you want functionality the fact you 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 what is the friction that prevents you 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 structured language that means you can 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 to use a new library I want to avoid 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 and we'll come back when we change the signature and I'm going to change the signature at the moment because as a 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 this is obsession that people have with 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 of today's mature widely used software 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 whoever calls it they are responsible 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 and in the small and if that means 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 the log and throw habit they had the 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 spoofing via repository or spoofing via 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 hosted on martin fowler's site and go to 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 [Applause]

Channel: GOTO Conferences

Views: 52,334

Rating: 4.8490567 out of 5

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, GOTOams, GOTO Amsterdam, Code as Risk, Kevlin Henney, risk, exposure to uncertainty, control models, encryption standards, firewalls

Id: YyhfK-aBo-Y

Length: 50min 26sec (3026 seconds)

Published: Thu Jun 22 2017