I just dedicate half an hour to an hour every day to exercise and to study a little bit, and I still get my other work done. It’s a discipline, and there’s no easy answer John. That’s the best. I think, unfortunately, you’re exactly correct.
Jim Manico
Recently I watched a talk from Tanya Janca on DevSecOps worst practices. The talk is interesting because I have seen similar practices during the early adoption stage of DevSecOps processes and culture. If you find that your DevSecOps practices have plateaued, chances are that your program is practicing some of the bad practices.
Below is a list of bad practices mentioned by Tanya:
I will only highlight a few of these practices and share my thoughts.
Testing a new tool for effectiveness is HARDER than we think. Usually POC on a vendor product has a limited timeframe (about one month plus). And you need to identify the teams that are suitable to test the products. If you chose the wrong team to test the product, you might jump into conclusion that this product is bad. Or if you test it on only subset of team, we still find it uncertain if the performance can be replicated to other teams who are using a different tech stack.
Tanya mentioned that one way we can do is buy perpetual license and trial it for about 6 months before deciding to purchase a larger contract. I think this is a good recommendation.
From vendor point of view, you should think about how you can let the security team try the important features of product and test it sufficiently so that they can make better conclusions.
Tanya gave an example about how the development team can disable tests in order to deploy to production. If too much permission is given to the team, some might abuse the permissions to reach their goal.
In general, I think CI is a wild jungle where you can run any scripts or workflows. But the crucial thing is to restrict the permissions for deployment (CD). If we control the permissions better, we can stop people from abusing deployment rights.
In some organizations, there are strict SLA requirements for deployment to production. For example, there can be a SLA that “NO CRITICAL or HIGH” issues in production.
This might be impossible to meet for some of the teams (Especially if they have legacy apps). Tanya recommends that Security team should consult other teams to see if this SLAs is feasible. Listen to see if the teams can fix the issues to meet the SLAs.
Create a docker.compose.yml file with the latest Gitea rootless image:
version: "3"
networks:
gitea:
external: false
services:
server:
image: gitea/gitea@sha256:ef6279e13e223d956bc417f299a3530795afcf79f3af429a5c893262c550a648
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
restart: always
networks:
- gitea
volumes:
- ./gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "222:22"Run a command to start Gitea as a docker image in your machine:
docker-compose --project-name gitea -f docker.compose.yml up -d
docker ps -a # Check if the containers are runningGo to localhost and you can see that a local instance of Gitea is running.
Create a Web app in Okta:
Configure the redirect URL: http://localhost:3000/user/oauth2/okta/callback
Save the Client Id and Client secret that will be input into Gitea
You must name the authentication to be the same name under the redirect url. In this case, I have name it as okta
http://localhost:3000/user/oauth2/okta/callback
The admin should paste the Client Id and Client secrets from Okta app to the Authentication Sources tab in “Site Administration”.
Sign in with OpenID
You will be redirected to Okta for authentication (ensure MFA is enabled preferably with FIDO2)
If this is the first time that you login with Gitea, you will need to fill in your username and email address to create an account.
Usual steps of creating a Dockerfile of your application:
| Dockerfile Instructions | Arguments |
FROM | Base Image or other Container Image |
RUN | 1. Passing commands (runs in shell) 2. Passing exec form: [“executable”, “p1”, “p2”] Execute command in a new layer. Examples: – Updating dependencies |
COPY | COPY is preferred to ADD as we know clearly that COPY will just copy files from local directory. ADD is useful if you wanna copy the content in a tar file. |
ENTRYPOINT | Define the command that will always be executed when the container starts. By default, Docker is using /bin/sh -c as the entrypoint. |
CMD | Define the arguments that will be appended to the ENTRYPOINT |
WORKDIR | Define where your commands should run. Saves the trouble of running to many cd ..... |
EXPOSE | Define the ports that a container listens. |
ENV | Setting environment variables that can be used in other instructions such as RUN |
FROM node:12-alpine
RUN apk add --no-cache python2 g++ make
EXPOSE 9091
WORKDIR /app
COPY . .
RUN yarn install --production
CMD ["node", "src/index.js"]
References:
Make sure the port publish setting (
https://stackoverflow.com/questions/66316400/cannot-reach-docker-container-port-not-bound-p) is positioned before the image tag so that it can override the image default settings.
docker run -p 9091:9091 -t spring-boot-dockerReferences:
“…make sure that the constraint is not allowed to waste any time. Ever. It should never be waiting on other resource for anything, and it should always be working on the highest priority commitment the IT Operations organization has made to the rest of the enterprise. Always.”
The Phoenix project
The NUMBER ONE constraint in Security department is people.
It is unlikely we can hire enough people to match the number of developers and operations engineers.
The way to free up our constraint (people) is to try to automate as many tasks as possible so that the people can do the things that are unique and contextual.
Another way is to take a preventative approach by educating developers and ops engineers on best security practices that they need to follow (this means secure by defaults configurations, having documentation and guides). The famous Netflix’s paved roads….
any improvement not made at the constraint is just an illusion, yes?
The Phoenix project