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.
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:
Breaking Build on False positives
Turning on a tool without testing
Artificial Gates
Missing Test Results (Results are not shared in a convenient location)
Missing Runway Testing (Not testing the tools in the CI pipelines to see the job duration impact)
Impossible SLAs
Untrained Staffs
Bug lost in Backlog
No Positive Reinforcement
Only worrying about your part (Not understanding whether another teams are facing any issues if you make the changes)
Multiple Bug trackers (Bugs tracking are scattered in different dashboards)
INSecure SDLC (Tools are not enough. We need more process and other activities like Threat Modelling)
Overly Permissive CI/CD (Skipping a process to deploy to prod)
Automation only in CI/CD
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.
Usual steps of creating a Dockerfile of your application:
Specify Base Image
Specify any environment variables
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
Copy the application files into the image.
Specify which port(s) for container to listen
Specify the command to start the 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"]
“…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?