An Intro To DevSecOps

DevSecOps is a new fancy term, mostly used for marketing purposes. Even if it's a new term, the concept of DevSecOps isn't really all that new (like many things) and didn't just come out of nowhere. Since we all have to go with the trend in the end though, I might as well give you a really basic overview of DevSecOps from a few different perspectives and points I want to cover personally.

What is DevSecOps?

As far as my understanding goes, DevSecOps means designing your product with security in mind and integrating it in a variety of ways. Most people that call themselves "experts" I have talked to (unfortunately) only see the security part as an addition to the normal DevOps along with DevSecOps being only reasonable if you're working with the "cloud" or are doing "serverless" development. Quite frankly I'm neither a fan of this way of thinking as well as the terms cloud and serverless themselves.

In my opinion, DevSecOps is or at least should be something that is thought of since the very beginning of a project and integrates security by design. From the programming language itself to threat modelling, monitoring changes and generally having a plan/roadmap of what you want to achieve. It's about keeping the developers safe, making it very hard to accidentally cause a severe security bug, so in the end, you can keep the users safe.

Please give some more technical examples

Since this was a more abstract overview of DevSecOps in my opinion I want to provide a more concrete list of examples which you can look at/consider to get the most out of DevSecOps.

Consider the language

Probably everyone has a favourite programming language or even multiple ones which they use. While the same goes for me, there just are some languages that are generally better for certain types of development. But this isn't all that you have to think about while choosing a programming language for your project. For example, I really love Nim. Nim has so many great features and it can compile to C/C++ or even JavaScript. It has an easy-to-learn, beautiful syntax and can be blazingly fast. Also, the generated C code (if you choose this option) is very well structured and easy to understand for most people who work with Nim and/or C.

The good thing about Nim is, that even if the project should fail you can theoretically compile it to C and continue working. Obviously, the structure that Nim generates will probably be lost, but it should still work.

Code quality consistency is really important though, so it's easier to understand the big picture and not always spending most of your time figuring out what the developer who wrote the code 6 years ago meant or tried to do.

Besides Nim I'm also a big fan of Elixir, Julia, OCaml and DRAKON. Each one of these has their right to exist and they all take their place somewhere.

Elixir is great for scalable, low latency, fault tolerant projects using the BEAM.

Julia, while it claims to be a general purpose language has a potential to hopefully/eventually replace R for data science and already is a great, easy to use language for scientists in a variety of fields.

OCaml is a fantastic functional programming language, which found its place and has a huge ecosystem, mostly in the fields of systems programming and financial engineering.

DRAKON, while being a visual programming language which is usually associated for teaching kids is a great language for visualizing the code that you've written and understanding it in a very different way. It's really underrated in my opinion, since it makes it easier to understand what your program does, find design flaws that either could impact the performance of your program, or even the security. Personally I use it to get an overview of something, or to complement other languages.

Every single one of these languages is special to me, but I'm well aware that I can't use them all at once or that one of them is just better suited for a project than the others. So if you choose a language please be aware of all the things it comes with, not even just from a purely technical side.

Know your supply chain

The current big thing to speak about, I know. Supply chain attacks aren't anything new though, it "just" has gained so much recognition because of the SolarWinds incident. While nobody speculated the SolarWinds incident specifically, there have been a variety of thought experiments in the infosec community how a similar situation could happen, what the effects would be etc.

This is also one of the major problems I see in infosec, always reinventing the wheel, while forgetting old practices. Sometimes we hear of a seemingly new term, even though it's probably an old technique with a few minor changes.

To mitigate and reduce the likelihood of such an occurrence you really should know your environment. Since every project is really unique giving general advice is pretty hard. I'll try to present what I know anyways, so that you hopefully can intuitively judge what to do and which rules to apply. Remember that this is just an introduction to DevSecOps though and obviously you can go way further than what I'll be able to write down here. Finding the right balance of efficiency and focusing on a certain perspective on DevSecOps is probably the hardest part anyways.

If you have a saying in a software project, make sure that you're really well informed about the project. Are you applying the basic principles of code reuse? Who can contribute and are the contributions trustworthy? What are the dependencies of your software project?

Documentation, documentation and even more documentation

Without a doubt the most fun part ever.

cough cough

As always documenting feels like it's the most boring thing you can possibly do, while you're doing it. Finding any decent documentation on a software project you're working with or on can make you breathe a sigh of relief like nothing else. I know of C++ code, which uses inline assembly that university students wrote, looking like the work of a madman without documentation. Taking your time reading these documents carefully and not trying to understand everything at once, will hopefully give you an insight into what's actually happening though. Even I write code that sometimes makes no sense to me just one day after I wrote it. Working yourself into code can be very difficult, not knowing what the variables are for, how they're used or what sequence of the code does what.

So for your own sanity and the sanity of others, please document your code or others. It's never too late to start with it.