Forem: Navee

Shift Security Left: Be A Secure Developer

Navee — Sun, 01 Dec 2019 17:38:41 +0000

The concept of Shifting security left in software development life cycle(SDLC) is not new. As a software developer, all of us know, how important data security/ privacy is. Most of us must have known about it, in one way or another, even if in different words or phrases. In this post, I am going to talk about what does it mean by shifting security left(for those who haven't heard about it before) and what can we do, as developers to adopt this mindset.

In the standard SDLC, you develop, test, put the application in cloud, iterate the process and when its ready to release for production, all security/ compliance checks come into picture. And we know that farther the cycle, more expensive it is to identify the problem and fix it. Expensive in terms of money and expensive in terms of time and of course in terms of our sanity.

So, security should not be an afterthought.

Hence, came the concept of shifting security left. Which means that rather than checking for security at the very right of the process, shift it to the left. Start adopting security/ privacy measures from the very start of the development. This can be pushed further left, where we start to analyse this from requirement analysis and backlog grooming.

Shifting left means adopting security by design. Possible issues later in the development cycle cannot be predicted. Hence it will be very helpful to be proactive and think about making the application more secure from beginning, rather than being reactive.

Adopting this mindset means that we can reduce the security vulnerabilities in our application, saving us a lot of time, money and most essentially stress to ourselves. You must have heard about death by thousand paper cuts. Its not always one big blow which can lead to malicious hacks but it can be 100s of vulnerabilities here and there.

It all sounds very easy. But is it?

As a developer, when writing code/tests or doing code reviews, there are so many things you have to focus on... Implementing the feature, writing clean/maintainable/testable code, writing tests and writing documentations. Without a doubt, we always want to embrace secure coding practices when coding and doing code reviews. But, with time constraint/ pressure, it is easy to miss this out. That can be because, it’s not imprinted hard enough in our minds as having to write unit tests/ making sure that code is maintainable. Adding this perspective proactively in your mental checklist, might take regular remainders and can become a habit with time.

Being familiar with the OWASP top 10 vulnerabilities, OWASP's ASVS( (Application security Verification Standard) and knowing good and bad practices for writing secure code helps a lot to remind ourselves about the measures we can take to be “The Secure Developer”. In addition, decisions we make as a developer, dictates how we can improve security of our applications. Decision about persisting data, using external libraries and using external code.

Data:

We know that most of the malicious hacks, leads to leak of User’s private data – their name, address, date of birth, email address, credit card details and Social Security number. So we need to make sure that those data are properly encrypted before sending it over the network and persisting them, so that they are secure.

However, what is more secure than Secure data? Answer is, NO DATA
If these private details were not saved in the first place, they would not be leaked and exploited. So, before persisting any data, we need to ask, WHY do we need to persist them. DO NOT persist any data, unless its absolutely required. If you have to persist them, make sure that, you take necessary measures to secure them.

Open Source Libraries:

Most of the applications today uses at least 1 open source library. Why? because there is no point in reinventing the wheel. But when using these external libraries, we need to make sure that they are reliable enough. Its really important to ask, if the library you are going to use is credible enough, if its regularly updated., What kind of issues are reported against it in github.

Open source libraries are the most vulnerable ones which can be exploited. You never know, that the library you are using might be mining bitcoins in the cloud.

However, in case of vulnerabilities in widely used libraries like openSSL and struts, you cannot do anything, except updating the library as soon as the fix comes along OR face the consequences as Equifax did. There are many commercial tools available for this purpose, that you can use.

Stack Overflow Driven Development:

Copying the code from Stack Overflow and pasting it without understanding what it's actually doing, is a common practice. All of us have done it at some phases of our career and we still do it. There was a research which researched about accepted answers in Stack Overflow and found out that there are many accepted answers which are out of date or insecure. It is really important to understand what the code is actually doing, before reusing it.

All of these sounds very trivial and obvious. But sometimes we forget about them. As a developer, adopting this mindset is really important. You don’t need to be a doctor to know that you should wash your hands to prevent spreading germs. But sometime, those notes in the bathroom helps. So this post is just that remainder.

There might be many other tips which you can adopt to embrace secure coding practices and make secure decisions. If you have any, please share it in the comments.

Docker: cmd VS entrypoint

Navee — Sat, 28 Sep 2019 11:12:48 +0000

Docker is widely used these days, but if you have not got any chance to work on it, then its high time to get familiar with it. This post is not going to be a tutorial about docker though, so it assumes that you have its basic understanding. If you know docker, you must know that to build a docker image, you need to create Dockerfile with several instructions in it. In this post, I am going to talk about two of those instructions: CMD and ENTRYPOINT which can be a bit confusing if you haven’t paid much attention to it.

Both of these docker instructions are used to define command/executables which is executed during container invocation. These are very similar but different instructions which can be used independently or together to achieve better flexibility to define what a container should execute. There are two ways/syntaxes to define them:

Exec form: (Preferred form)
CMD [“executable”, “arg1”, “arg2”]
ENTRYPOINT [“executable”, “arg1”, “arg2”]

Shell form:
CMD executable arg1 arg2
ENTRYPOINT executable arg1 arg2

Use cases:

CMD

Used to provide all the default scenarios which can be overridden.

Cmd instruction is used to define:

Default executable

This instructions is used to define a default executable for a container to execute. If you want to create a generic docker image, where users can pass any supported command to be executed on container invocation, then this instruction is the one to use. Entrypoint instruction should not be defined in Dockerfile for this use case.
CMD [“executable”, “arg1”, “arg2”]

Default arguments

This instruction can also be used to provide default arguments. For this use case, we don’t specify executable in this instruction at all, but simply define some arguments which are used as default/additional arguments for executable defined in the entrypoint instruction. Thus, entrypoint instruction is required in dockerfile for this use case to define an executable.
CMD [“arg1”, “arg2”] ENTRYPOINT [“executable”]

P.S: Anything defined in CMD can be overridden by passing arguments in docker run command.

ENTRYPOINT

Used to define specific executable and arguments to be executed during container invocation which cannot be overridden. This is used to constraint the user to execute anything else. User can however define arguments to be passed in the executable by adding them in the docker run command.
ENTRYPOINT [“executable”, “arg1”, “arg2”]

Demo

For the demo, let's take the following dockerFile which fetches necessary cowsay and screenfetch libraries so that we can run these commands when running the container.

Demo 1 - Use of CMD to define Default executable

FROM debian:jessie-slim

RUN apt-get update                                      && \
    apt-get install -y --no-install-recommends             \
        cowsay                                             \
        screenfetch                                     && \
    rm -rf /var/lib/apt/lists/*

ENV PATH "$PATH:/usr/games"
CMD ["cowsay", "Yo, CMD !!"]

Build the Image:
docker build -t demo .

Run the container:
docker run demo

This will run the default executable specified in CMD instruction and output following.

However, you can override this executable, when running the container as
docker run demo screenfetch -E which will output

Demo 2 - Use of ENTRYPOINT

If you want to restrict users from passing any other executable, you can specify 'ENTRYPOINT' instruction as :

FROM debian:jessie-slim

RUN apt-get update                                      && \
    apt-get install -y --no-install-recommends          \
        cowsay                                          \
        screenfetch                             &&      \
    rm -rf /var/lib/apt/lists/*

ENV PATH "$PATH:/usr/games"

ENTRYPOINT ["cowsay", "Yo, Entrypoint!!"]

Build the image again and run this container as:
docker run demo

This will run the executable specified in ENTRYPOINT and output following.

With entryPoint defined in the docker file, if you pass an executable in the docker run command, it will not take that as an executable, but, as an argument for the executable defined in the entryPoint instruction. So if you run following command,

docker run demo screenfetch -E

It will output:

As expected, the arguments passed in the docker run command, is appended in the executable and argument, set in the entryPoint instruction.

Demo 3 - Use of ENTRYPOINT and CMD together

If Entrypoint is defined, anything defined in CMD will be taken as arguments for the executable defined in Entrypoint.

FROM debian:jessie-slim

RUN apt-get update                                      && \
    apt-get install -y --no-install-recommends          \
        cowsay                                          \
        screenfetch                             &&      \
    rm -rf /var/lib/apt/lists/*

ENV PATH "$PATH:/usr/games"

CMD ["Yo, CMD!!"]
ENTRYPOINT ["cowsay", "Yo, Entrypoint!!"]

Building the image from above docker file and running the container with docker run demo will output:

As you now know, the argument defined in CMD can easily be overridden by passing other arguments in docker run command, if you execute docker run demo Overriding arg passed in cmd, It will output:

Thus, the main point to remember is CMD is used to provide default executable and arguments, which can be overridden, while ENTRYPOINT is used to specify specific executable and arguments, to constraint the usage of image.