[00:00:10]
>> Thank you. My name is Shelby Allen Good afternoon we're here to talk about secure software development so just a quick overview we're going to cover some topics kind of before during and after you write the actual code 1st off we'll talk about designing secure software kind of at a low level some general patterns that you should follow some common trip ups some common bugs and then some resources that you can follow later we'll talk about after you've written code ways to validate it and some kind of common and growing research techniques to validate that your software secure So 1st off why do we care so much about writing secure software in some sense this is a question that answers itself but as you write a lecture you should probably address it at the beginning one of the perspectives is pretty straightforward if we're writing something for other people to use we care about their perspective and we want them to have a good experience a software security bug is also a bug and it affects their experience so we should try and minimize the bugs.

[00:01:13]
Next we have to deal with the code that we write we have to deal with code that other people write sometimes we think that the code that we're dealing with that makes us so angry is actually code that we wrote in the past if we're going to deal with our own code then we should probably try and make it secure maintainable and clean Also we care about user privacy and safety but actually we probably just want to stay out of the news so what we're going to do is really go into some design patterns you're probably familiar with that term if you're familiar with software development.

[00:01:48]
Design patterns there are patterns that are vetted time tested battle tested solutions that solve common problems they're generally reusable or effective self-contained can help in a variety of applications some nonsecurity examples that you may be familiar with or singletons factory's iterators and when you start focusing on security there are some common problems that arise from common design patterns that help just help address those problems so what we're going to do is going to go through a couple of those examples 1st something that will come up a number of times is the idea of a trust boundaries so kind of a sterile definition would be a boundary where program data or execution changes its level of trust instead of trying to pull that apart let's go with if you go with a few examples let's think of a program and how that program should behave before after you've decided that a user input has been sanitized or validated or considered safe or an application and how it should behave before after you verify that a user is actually that user after they've been cryptographically verify it in other words or a Unix application that has different components that should only run if you have root access and components that should run as an unprivileged user And then lastly not even the code itself but let's say you have a database that contains various pieces of information that should only be accessed under different situations each of these demonstrate a line in your application a trust boundary that on one side you treat the user and what how they interact with your application one way and then on the other side something else.

[00:03:27]
So a simple example if you're writing a command line application and you're getting input from the command line before you do anything with it you should validate that input. Not so simple an example if you're writing a web application that means that most of your input is coming over the Internet via an A.P.I. some information that you're receiving is on a form and that form has information that's going to be stored in a database but not all of that information is secure or important but some of it is like a sick social security number sometimes you'll be writing applications specific to an industry that has very specific security requirements a social security number is a very popular example of one of those things in that situation you'll need to handle the information differently before it's even stored and especially differently if anyone ever tries to access it these are trust boundaries and if you write a non-trivial application you're going to have more than one some general ideas to keep in mind when you're dealing with trust boundaries at the bare minimum isolate the outside world from inside your application any interface between the outside of the inside should have a layer of verification better yet any boundary that you identify you should have explicit controlled interfaces for how you cross that boundary about these interfaces about these trust boundaries these are not ideas that come up in the convenience of writing your software these things should be deliberated on it before you write that code and they should depend on roles and permissions how you intend to handle the data not the convenience of how your code has already been designed there's a wall there.

[00:05:09]
Related trust boundaries mentioned a couple of times input validation this is if let's say that we've decided on a trust boundary and we know that we care in the form of that data from one side to the other how do we make sure how do we determine whether that data should cross as is or whether it should be modified or not allowed at all whether or not it should be allowed it all depends on permissions part of input validation is deciding whether or not the input should pass at all and a little bit more detail there are some other things you need to consider whether or not it matches the entire format that you're expecting information there are some popular libraries like proto buffer message pack file formats like Jaison and X. amount that will help with this but they are not the entire story and sometimes they're treated as such things like types when you're receiving information on one of these fields making sure that it matches the type of how it's going to be treated throughout the rest of your application even more specific even if it matches that type there are situations where a type of data has a value that makes no sense to your application for example we're dealing with a project right now that deals with some geographic information specifically latitude and longitude latitude or longitude of 256 does not make sense that is literally out of this world so you need to have input validation that makes sure that even if it isn't the format that you wish even if it's the type that you desire that the values make sense these are all things to keep in mind with input validation also related to the value range kind of a special cases nil mole none especially when you're storing values in a database this is something that you need to decide beforehand whether it makes sense for input to ever not have a value when you're storing things in a database there are times when this doesn't doesn't make sense if you have a person you need to have a unique identifier that this person can refer to if you're familiar with sequel there's you know the classic like not know when you're defining your table schema.

[00:07:08]
Another design pattern defense in depth this isn't directly related to your application and how you write it but rather the environment in which your application will run these this will have an effect on what data will reach your application and if you're deploying an application then you should have these things in mind what guarantees it gives you and specifically what guarantees it does not network based solutions should be in place fire walls idea says I.P.S. as you're familiar with these things anomaly detection if you're fancy even on the host itself there's a variety of solutions which will help to make sure that when and put reaches your application that there's some level of guarantee any virus applications a more general thing principle of least privilege to users Yeah it's a pain every time my son wants to update fortnight but there's been one or 2 times where he's wanted to download some auto clicker application that probably has a virus and it but least privilege makes sure that he's not putting anything on there that I don't approve operating systems all major versions have various aspects of hardening Linux as packs your security as a Linux is very popular when DOS has it as well make sure that these are in place.

[00:08:22]
A little bit more abstract of a principle but no less important simple code is easier to reason about it's easier to maintain it's easier to find bugs. It is into it is an intuitively difficult to write simple code this does not mean the code as designed as it occurs to you as you write it there were times that your writing code and you're realizing that you're duplicating functionality and you need to make a decision will do I just continue to write out the duplicate functionality here or do I stop context switch put this into a separate function and refer to it individually in other aspects of code that's a Single Responsibility Principle it takes extra work to write simple code so this is not just lip service to vague design principle don't repeat yourself keep it simple stupid these things all are popular phrases that enforce singular point is that when you're writing code this is a deliberate act to make sure it's simple the next person is maintaining the code maybe you.

[00:09:23]
As depending on your language this depend this may involve using names spacing other code concepts classes functions avoid clever code I swear if you were designing a solution that you think would be cool using functional programming lambdas closures metaclasses or especially template metaprogramming I urge you to really consider whether that solution is necessary if you've never debugged a problem using that uses template metaprogramming you never want to it is a pain be absolutely sure that if something has to be clever that it's absolutely necessary another design principle in session management if you're taking input from a user and you're tracking that users interactions over time you need to maintain that within a session when it comes to things like this there are some unintuitive problems I would recommend using a standard library most languages most frameworks have ways to do this for you I guarantee you that if you write it by hand there will likely be situations that you will not anticipate.

[00:10:30]
With a few notable exceptions they do a better job one of the reasons why heart bleed in the you know marketing symbol for which you see here the reason why it was such an extraordinary event is that an open source library was discovered to have a vulnerability and that caused a lot of hubbub the reason why that's exceptional is that it very rarely happens you should still consider open source libraries 1st because they can be vetted by 3rd parties which raises the likelihood of it being secure when you're handling passwords salt hash structure passwords at entropy again if you are using if you're storing passwords you should have a Consider using standard library.

[00:11:13]
Also related to session management session tokens themselves cookies these should be pseudo random it's really easy to want to do this by a user ID some identifiable information or a guessable number you should not do this and you should not increment a counter as makes it way too easy to hijack or look into other sessions.

[00:11:37]
Lastly for session management it's getting more popular use to factor authentication all the cool kids are doing it. All right those in Design Patterns Now let's talk about some common bugs. Try to arrange these in terms of lower level to high level so if you don't deal with C. or C. plus plus God bless you you can take a nap briefly but we'll get some higher level concepts in a minute 1st common bug you've probably heard of it buffer overflow quick review this occurs when you read too much data into a buffer in the right continues past the bounds of the buffer What are some potential effects of this well at least a knock us of the most innocuous of which would be a denial of service if the user knows that they can feed in a certain amount of data and crash replication then this is still affecting service that you wish to provide with your application but there are worse situations overwriting data on the stack or being able to overwrite Mehta data this is what leads to someone being able to use your application to arbitrarily execute code on a remote machine you don't want that to be you use after free this is when you've you're using dynamic memory and you've freed it you're no longer using it but then at some later point you're still accessing it according to specs This is technically undefined behavior but in situations like Heartbleed we can see that unspecified doesn't necessarily mean innocent that that information is still in that dynamic memory until it's being reallocated and then re initialized by some other application very rarely does anyone sanitize dynamic memory before they free it so that information is still there and the example given here could be 100 any arbitrary value or you know the values that are being stored by Open S.S.L..

[00:13:27]
Pointer aliasing This occurs when for some reason you have decided to use 2 pointers to Al to access the same location in memory since they're accessing the same location in memory if one changes the value then it changes for the other one as well in some very specific circumstances this is something that you want like a linked list or recursion but often it is not as a matter of fact in later versions of C. plus plus there are mechanisms that let you avoid this kind of thing and I would highly recommend if you're writing at this level of programming language that you should use more recent versions of those languages so you can take advantage of these mechanisms related to pointer aliasing type confusion let's say you have 2 in dresses to a point of data but both of them expect that data to be in a different format sometimes as really unintuitive like an integer 1010 means different things whenever you're looking at it from an energy perspective or a flow perspective doesn't get really hairy if you're dealing with more complex types you know they're just bits in memory and so if you access it at a certain point that format can look very very different and then again if you have 2 points of access that's modifying this information you can come up with some pretty crazy results this is particularly a problem in function pointers as a matter of fact function pointers should be on that list of fancy things that if you really think it's necessary then yeah go ahead and do it but check your documents.

[00:14:54]
It leads to something more problems and solutions a little more abstract race conditions in this particular example you have 2 different threads and they both modify to different values and lets say that you need to access both of these values at a later time well depending on when you access them those 2 values can be any number of things and this is due to how the processor can enter or leave instructions in different threads.

[00:15:23]
For situations like this again there are language mechanisms that can help account for these situations don't reinvent the wheel if you're writing multithreaded code you need to have an understanding of the architecture for what you're writing as a matter of fact I did put it on here $0.00 is also off so a possibility there's different caching mechanisms that different processors will use and so really if you're dealing with multithreaded applications you in less the application or the library that you're writing is very specific to that space and you've decided that what exists is not sufficient for you then you should be writing with what's already there a little higher level outside of the C.C. plus plus range is sequel injection to be on regardless of whatever loading widget you're writing in if you're writing an application at some point it will probably need to store and then retrieve data at a later date.

[00:16:22]
Sequel injection occurs when a user input is improperly. Verified and sanitized and they are able to execute execute semi arbitrary sequel code by escaping the user input one of the more common examples of this let's say like in the example given here you have a username and password and then you have a clear that says hey if these 2 you know if this leads to a validated user then selected this data if someone can add to the end of that query or if the see if the username and password match or if one is equal to one then give me the data then of course that situation matches they'll be like it's a data that's happened a lot it's this isn't a contrived example and so again use libraries as a matter of fact a lot of libraries for languages that manage sequel code will have functions there various more than one function that will sanitize and puts a different levels in for different situations so you should definitely review whatever's available to you white list Cross site scripting this is kind of a general term there used to be a beautiful day in age when your web browser didn't execute code and it really actually just rendered but now they're basically remote code execution engines and it's led to a huge problem where.

[00:17:46]
There's a huge space of security concerned with well if I'm going to execute code which code is safe I'm downloading it from all over it's being some is being supplied by the user some I'm reading from a database Cross site scripting occurs when some of that code is reached from a place that perhaps it shouldn't like you can formulate an H T M I I'm sorry H T M L U R L with some javascript added as part of a parameter that with someone else were to click on that link javascript would be executed in the site that was loaded or you can get.

[00:18:19]
If you can get javascript stored into a database and if someone access is that record then that is pulled out and then ran this going to allow for execution of arbitrary code on someone else's machine now these last 2 in particular I talked a little bit about some solutions not so much on the cross site scripting but is a good time to talk about some general resources because these are some higher level problems it's not just the same as just like well make sure you never use your pointer again these are you know cross disciplinary problems so let's are talking about research resources 1st read the.

[00:18:53]
Manual if you're using a language a platform a library something that has documentation then read it that does not mean a Tauriel it does not mean a quick start guide the actual documentation when you decide to use a function do not guess on its functionality Besides whether or not it accomplishes your immediate goal read the documentation around that function because more often than not especially with cryptographic libraries there will probably be consequences beyond the one that immediately accomplishes your goal.

[00:19:26]
They often have those side effects. Some resources that you can follow if you're dealing with low level languages I highly recommend looking up coding styles there's a really popular one for C. called cert coding styles are not just about pretty code they have embedded within them similar to design patterns wisdom of the ages practices that help make the language readable less likely to have bugs more likely for you to accomplish your goal without having some of the problems that we've identified so far as matter of fact even beyond seen C. plus plus there are language style guides out there for just about every language that you might want to mess with I would highly recommend after you get your little like how to get a hello world out of the way finding a good coding style website Google has been known to release a couple for different languages I'm sure if you look up and certainly cheer coding style guide you will find some popular ones and before you start developing your own opinion consider that people who have used it for longer may have some good reasons for how they think the code should be written now open Web Application Security Project is a Web site a fantastic Web site for things that may not be tied to a particular language but are very pertinent to security they have a variety of resources that hurt thinking that your application might be used by someone else you really should give them a look 3 examples I've given here a Wasp has kind of a top 10 security problems in code and what you should do about them in a single P.D.F. you should be looking at it.

[00:21:03]
Even specific to certain problems very popular problems these may sound familiar because we talked about in just a minute before sequel injection prevention cheat sheet for students you love this kind of stuff cross-eyed scripting prevention cheat sheet check them out. Even at a higher level let's say that you are you've developed for many years and now you're managing someone else developing a project or and you need to be responsible for the process of developing software and its entire life span and you want to make sure that not just the code itself but the process around the development the deployment of that code you want to make sure that each of those steps are good in terms of security because I can tell you they are very much related to security Microsoft has got you covered they have an entire website dedicated to a secure development lifestyle you should give a lifestyle lifecycle if you give it a shot I mean it's a good lifestyle All right so let's say that you've written some code you've tried to follow each of these things but you're a conscientious fellow you want to know well do I have any issues in my code and there's a variety of techniques to do that 1st we're going to cover kind of a high level concept as to what types of analysis are available and why they differ so so much generally when you're talking about analysis you kind of have 3 goals 1st off you don't want any false negatives if something says that it's a problem or I'm sorry with false negatives you want to find everything you know you want your program to be secure and so your desire is to find everything there that's called soundness sorry a little bit of OK I will get there quickly completeness no false positives if something fires if you run an analysis it tells you something you would like it to be permanent you would like it to be pertinent Lastly you would like to know that the job is done terminations if you run an analysis you'd like to know when it's finished generating these facts and you can start working on addressing them.

[00:23:02]
So thanks to the halting problem soundness and completeness and terminations cannot be guaranteed all the same time and so as a result of that we need to separate our analyses limit our expectations focus on certain problems at a time in this kind of leads to 2 general branches of software analysis this is kind of like where where the work that I do on a daily basis comes in is different types of software analysis so what we have on the right here just kind of give an example of soundness versus completeness is some code that has been separated into what's called a control flow graph and you can see that each of the instructions have been separated into a directed graph.

[00:23:45]
For soundness sometimes you look at this could relate to OK where is memory access to every time or when when is a value received an assignment well soundness what it can do is it can show you every single place where a single instruction would make an assignment but it can't tell you if that would ever happen when the application runs it can't tell you whether that time that an assignment is made will ever happen or the circumstances under which it happens but it can to show you every spot where an assignment is made completeness would be more like when you've run the code and you can say hey I received an issue I had a bug at this point but I can't tell you if that's the only time it'll happen if you know you get one you're sure that it's a bug but you'll have to try other inputs to see if it will happen under other circumstances so this is the separation between static analysis and dynamic analysis So we'll talk about static 1st static means that you're not actually executing the code you're looking at the code running analysis on it and trying to find sound analyses these tools can range.

[00:24:59]
From simple to very very complex some. Static tools you'll already be familiar with and you will probably say that static analysis I do that anyway and then there are some that are more advanced than that that can help really drill down to specific issues you want to learn more about adding these things I would I want to say a free when you should definitely consider adding any of these if they're not currently a part of your process some of them are relatively easy to add for example let's get one thing out of the way code reviews are a type of static analysis you know when you're submitting your code you are positive when you're working with a group you should make a practice of before you say that code is baked you should look at it as if there is a problem and see if you can find anything off and you can ever surprised how it's easier to find problems in someone else's code and set of your own Well it's because you're looking at your code like it works and you're looking at there's like it's messed up trying I know it's a mental exercise which none of us love but if you consider it a little higher level actual technical tool lender's these are things that are kind of quick and dirty they passed over the source code they can do anything from you know sometimes their automatic styling formatters sometimes they're there these are things that in your integrated development environments in your ID ease that will find simple issues and errors over syntax so you sent X. and style checkers some of them are a little more advanced than that and they can find more subtle bugs related to reading the documentation related to using libraries if you're using a language that has lender's has style Checkers has syntax checkers you're really not doing is going to job as you could if in less you're using these things.

[00:26:40]
I love them as much as the next guy but you know I know try to integrate some static analysis tools into it depending on the language that I'm writing but there is something to be said for using the environment or before you commit that code running it through some sort of checker and of course the tools available depend on the language but I guarantee you that if you're using a language that you know most of us are familiar with there's going to be some sort of low level Linter available for it and you should be using it this is especially valuable when collaborating again this goes back to keeping your.

[00:27:12]
Keeping your code simple keeping it uniform This makes it easier for you to read later and for other people to share code a little higher level their compiler also has a lot of static analysis tools built into it if you're using a low level language particularly with C. and C. plus plus Do not ignore the warnings they're there for a reason you should enable them you should enable more of them you should do warning all extra that antic they're almost never spurious and if they are you can ignore them in a very specific place after you have decided that that very specific place is actually an exception again like when you're writing your own code if a warning is generated then you should assume that it is a problem not that the compiler doesn't know what it's talking about.

[00:27:58]
When you're using C. and C. plus plus there's also some things specific to security certain compilation flags like stack protector pi. A couple of these. I can go over really quick like in stack protector we were talking about buffer overflows how they might be able to address run in different areas of code stack protector adds like a protection variable that if you enter a certain area of code and then it tries to jump somewhere else if that variable is an Access to get in and cleared then it can fire in error and it can know that someone is trying to move the path of execution somewhere else PI's for also related to remote code execution pie adds address space layout randomization or a S.L.R. there is a whole stream of different types of.

[00:28:48]
Attacks that assume and this was true for a while that different libraries were stored in the same location every time so they knew that if they could escape the path of the execution then they could move the program counter to just a hard coded point and they knew that if that machine was running that particular library then they'd be able to access arbitrary and secure functions by ads that randomization for your application rel row if you're dynamically loading libraries it protects those from being executable and then claiming a particular compiler has a variety of other tools as well sanitization for when you're storing different things and memory like addresses running a level higher than that still in static analysis this is when so those are kind of pertinent to particular languages.

[00:29:38]
So if you have code you want to use a different tool specific to security these are generally called static applications security testing tools these are techniques that you'll find more often in independent open source applications or commercial products a popular example of each is flaw finder and Coverity these implement things like control flow analysis that's like again like how does the program's execution flow depending on different variables in data flow analysis with a good example of that one so that's how does the data flow through a program when we're talking about input validation for example one of the concerns is that if something is not validated then it could be malicious and reach a certain point in code and could you know do something have some unintended behavior data flow analysis has a subsect called taint analysis where it can highlight places where external data is reaching the application and potentially vulnerable places in your code like certain C. functions that have been known to be in secure and can run an analysis on whether it might be possible for input data to reach those points and code again this is a static analysis tool so this doesn't mean it's guaranteed that data would reach that place but it could say that well according to your how the data flows in this application the logic that I can read statically it looks possible again like this is something worth addressing aliasing analysis addresses pointer aliasing you might see that there's different types of in Hull says that match some common classes of problems value range analysis also related to field validation what value or range of values can a variable hold at a particular time if there's a particular point in your code that expects it to be within a certain range and fails catastrophic Lee if it's not then value range analysis can take that risk that expectation and let it percolate through the program flow and see if there's a point where the input is not constrained in that way.

[00:31:35]
Lastly for static analysis we have the big guns we've got formal methods this is a name this is kind of even above code itself is about the design of an application and its architecture these techniques they've kind of suffered from scale ability problems for that reasons for large code bases because you have things that really muddy this type of analysis you know things like Error handling things that completely jump the flow of execution but the technology is getting better they have a lot of use this has been used in part into the security realm formal methods were used to verify different parts of the W.P.A. to protocol incidentally a vulnerability was still found afterwards and it was found that late while D.P.A. or while formal verification was used to verify mathematically individual components it was the intersection of those components that was not formally verified but for further reading this is kind of high research abstract you can look at things like formal program verification model checking static symbol execution abstract inverter partition or if you're working on your masters you should go and take the software analysis and test class covers a lot of interesting formal methods and they're definitely up and coming and it's you know since security is about trying to get as close as possible to reaching a guarantee formal methods are one of those things that like from a design a high level perspective we want to try and get as many guarantees as possible so it's definitely growing in that space so lastly we have dynamic analysis this is the type analysis that is not sound we don't know whether or not we're missing some bugs but if we do get one that we know it is for real they're proven it's because it was found when the application was actually running we said not sound most applications if you think about it have an infinite input space there is no way to run every particular input through an application through every potential execution path that is why dynamic analysis cannot be sound.

[00:33:31]
1st off so we've got some examples of dynamic analysis this 1 May seem a little room in Terry a little boring or annoying especially when you're writing for collaborative projects tests good old fashioned tests they look at functionality they run that functionality actually run it and then have an expected output you should be writing tests and you should be writing at least these 4 different kinds of tests these kinds of tests unit testing unit testing specifically tests a small portion of code is good for if you have functions for field validation you should have unit tests that make sure your field validation code truly does have the bounds that you will trust it with later on in your code and Gratian testing this is a wider range this is you have separate components of your application that are interacting with one another this is where you let the you feed an input at one point and then somewhere deeper on through code you want to make sure that the state is as you expect it this is about validating your trust boundaries making sure that the code is executed on both sides did what it was supposed to do these are both good anticipatory techniques but let's say you still find a bug God forbid fix the bug write a regression test this is that this is a test specific to that bug should cite that bug and then it should be ran as part of your testing suite so that that bug never happens again this is a part of learning when you do find these find these problems and then lastly good old fashioned human testing there's nothing like it good analog testing will find you all sorts of bugs and then of course when these are found in addressed they should be reflected in your testing suite.

[00:35:15]
A little higher level rather than tests we have fuzz testing this is an area little more pertinent to kind of the research side that we do. Is when you're running an application time and time and time again with semi random inputs as quickly as you can you're looking out for things like crashes hangs and valid accesses literally like whatever you consider anomalous behavior and you can detect in the run of an application with whatever instrumentation you're using whatever you can kind of like check on at a certain point in your execution then you can look forward and testing now sometimes this is a simple as just generating random information and feeding into a console application or other times it's considerably more complex web applications graphical applications that taken you know mouse clicks or you know dragons of a mouse like all these sorts of things are still considered inputs to an application it becomes sometimes difficult to the verb is harnessing So you need to harness an application in order to fuzz it and sometimes that problem itself can get more and more complex but once you can once you feel that you've adequately done that and there's no guarantee that part can be iterated on but you can start focusing and then a fuzz or I guess I should shout out one of the open source Pfizer's that's available to you today on the Internet American fuzzy law or fell these different applications once you've harnessed an application you just kick them off and they'll go to kingdom come generating some random inputs according to the constraints that you've given it and we'll let you know if the application crashes when it does you have found a bug and you can address it and so this is a great thing to kind of do.

[00:36:55]
On the side another tool if you're on Unix systems is valgrind if you're writing C. in C. plus plus and you've tried to abide by every other thing in this talk you should still run member this is a fuzzing application that will feed all sorts of shady inputs in your application and will let you know if there's memory corruption errors there's no.

[00:37:15]
And of part of this talk is that there's no amount of anticipation or design or planning that will make your software bug free and so you have a responsibility to do some form of verification and if you're running it writing something in C. in C. plus plus doubly so used.

[00:37:32]
Some final tips from some ups know your tools this is paramount read the documentation understand your platform when you're writing code Think carefully about the roles and permissions and trust boundaries I know sometimes we get wrapped up in just getting the application to do want but we should think about what it shouldn't do as well when we're writing the application when dealing with cryptography and particular user well vetted library read the documents for it I've said it before and I've said it again probably because I've been burned on it burned by a before there are usually until is a paid it affects for individual functions in cryptographic libraries you should review the documentation and make sure that even if something works that it actually gives you the guarantees that you anticipate a little more general but still related used managed to which is what appropriate we've talked about I think the dangers of C. in C. plus plus enough sometimes there are appropriate sometimes they're necessary often very often they're not Python java javascript rust over C. and C. plus plus they manage memory there's as you can tell there's a significant portion of this lecture that just covers memory access issues you can save yourself a lot of pain if you're writing an application that would work just as fine it isn't super performant necessary that it needs something like C. or C. plus plus.

[00:38:58]
If you still decide to use it follow best practices there's a lot of literature out there there's also you know different versions of C. plus plus you should be using near the latest some of these problems have they've attempted to address it but since C. plus plus is a federation of languages you can still do the dangerous things you should be using smart pointers careful memory management bounds checking thank you very much for your time given questions.

[00:39:30]
That was easy Michael. So. There's. Depending on which part of the lecture you're talking about when you're like winter's itself they're pretty obvious when you're setting up a code environment when you're starting a project like in our situation like when we're collaborating with other workers this should be early on in the process I should listen to my own advice because recently I've worked on a project where partway through the process we've started adding some Centex and some style checking and so there are a couple of commits that are particularly ugly and trying to make it once again uniform for additional team members to join other things like the static and dynamic analysis tests these are something when the project is a little more feature complete if it doesn't do what you wanted to do yet then there might be modifications sufficient that any type of higher level analysis wouldn't be as appropriate unless the application were already doing what you intended it to as an answer question thanks you no questions so.

[00:40:44]
You. Like recommendations between different open source libraries. Is one that. I think. That's an interesting point I suppose that's a point that should be added in here I suppose we talk about in terms of languages in particular but also you know recent versions of libraries as something very pertinent especially in regards to Open S.S.L. this is something that for Hartley and update needed to be made and then once an update made everyone was like up to your servers and so using updated libraries it is very important I think kind of a combination between that and making sure you're using something that can be vetted by 3rd party sources are both very important that's an interesting point to add on top of the like being aware of your environment making sure that you're using the latest libraries is very important to your questions All right thank you very much.