Skip to content

Tag: DevSecOps

Never stop learning -> To perform better

  • Spend time to dive into the development framework or security documentations that you are not familiar with.
  • Do it everyday consistently in an allocated time.
  • Understand the Framework hardening guideline. Study the framework security docs.

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

Notes on “DevSecOps Worst Practice by Tanya Janca”

Jun 8, 2023
Presenter: Tanya Janca, CEO and Founder, We Hack Purple

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:

  1. Breaking Build on False positives
  2. Turning on a tool without testing
  3. Artificial Gates
  4. Missing Test Results (Results are not shared in a convenient location)
  5. Missing Runway Testing (Not testing the tools in the CI pipelines to see the job duration impact)
  6. Impossible SLAs
  7. Untrained Staffs
  8. Bug lost in Backlog
  9. No Positive Reinforcement
  10. Only worrying about your part (Not understanding whether another teams are facing any issues if you make the changes)
  11. Multiple Bug trackers (Bugs tracking are scattered in different dashboards)
  12. INSecure SDLC (Tools are not enough. We need more process and other activities like Threat Modelling)
  13. Overly Permissive CI/CD (Skipping a process to deploy to prod)
  14. Automation only in CI/CD
  15. Hiding Mistakes and errors

I will only highlight a few of these practices and share my thoughts.

Turning on a security tool without thorough testing

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.

Overly Permissive CI/CD

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.

Impossible SLAs

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.

How to integrate Gitea with Okta (Authentication)?

Start up Gitea

Create a docker.compose.yml file with the latest Gitea rootless image:

version: "3"

    external: false

    image: gitea/gitea@sha256:ef6279e13e223d956bc417f299a3530795afcf79f3af429a5c893262c550a648
    container_name: gitea
      - USER_UID=1000
      - USER_GID=1000
    restart: always
      - gitea
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
      - "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 running

Go to localhost and you can see that a local instance of Gitea is running.

Okta integration

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


The admin should paste the Client Id and Client secrets from Okta app to the Authentication Sources tab in “Site Administration”.

Test the integration between Gitea and Okta

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.

How to Dockerize your project?

Creating a Dockerfile

Usual steps of creating a Dockerfile of your application:

  1. Specify Base Image
  2. Specify any environment variables
  3. Specify commands to run on the top of OS layer such as:
    • downloading or updating dependencies
    • add groups or users to run process instead of root
  4. Copy the application files into the image.
  5. Specify which port(s) for container to listen
  6. Specify the command to start the application
Dockerfile InstructionsArguments
FROMBase Image or other Container Image
RUN1. Passing commands (runs in shell)
2. Passing exec form: [“executable”, “p1”, “p2”]
Execute command in a new layer.

– Updating dependencies
COPYCOPY 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.
ENTRYPOINTDefine the command that will always be executed when the container starts.

By default, Docker is using  /bin/sh -c as the entrypoint.
CMDDefine the arguments that will be appended to the ENTRYPOINT
WORKDIRDefine where your commands should run. Saves the trouble of running to many cd .....
EXPOSEDefine the ports that a container listens.
ENVSetting environment variables that can be used in other instructions such as RUN
FROM node:12-alpine
RUN apk add --no-cache python2 g++ make
COPY . .
RUN yarn install --production
CMD ["node", "src/index.js"]


Running a container

Make sure the port publish setting (-p) is positioned before the image tag so that it can override the image default settings.
docker run -p 9091:9091 -t spring-boot-docker


Purpose of DevSecOps and its future

“…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