DevOps is the thing that every organization is looking up to from the last half-decade and almost all tech giants are following that even there are startups which made millions providing solutions on DevOps but then what’s next? What’s next big thing after DevOps and then it comes DevSecOps.

What is DevSecOps?

DevSecOps is nothing but adding security to DevOps. Let me give you more overview on this. Usually flow for developing any application is code(develop) -> test (QA) -> release build and this is for DevOps.

When it comes to security in DevOps either after testing is done or build is being released usually organizations hire pentesters to test the hardness of application and if any negative feedback from pentesters will move the application back to the development stage and again the process starts. Developers if they have good security knowledge, they will solve the issue and process moves forward but if they lack security practices or knowledge then again, they need someone to explain it or they must research on that. Sometimes there will be a situation where developers need experience for specific issues but cannot learn it from anywhere similarly there are many scenarios which are hiccups to release stabilized application and takes more time like 5x time. Here comes DevSecOps where the organization will be having a pentester or security analyst who will be coordinating with the developers with the possible vulnerabilities that the application might have and how to prevent them. This thing will skip pentesting step after QA testing which will save lots of time and effort.

In this article, I am going to share a checklist for development teams, developers, architects, dev team managers which would help you to build a secure application. This is just a quick list. There might so many things that I might have not included feel free to comment and add the information. Most of these points are self-explanatory and I will add more information if there is anything complex.

• Hash the credentials before storing them to the database and add salt if possible.
  • Whenever you are storing any credentials in the database you must hash them. Use hashing algorithm like Argon2 and salt is some random data you will add to the username or password so that even the database got compromised the hackers won’t get the exact username and password. I will write about what is hashing and salting in more details soon so stay tuned.
• Never use hardcoded values or don’t hard code the sensitive data in configurational files.
• Use CSRF tokens while posting the data.
  • CSRF will help the application not to do forgery of the request from other sites and use CSRF tokens whenever you are posting the data from web application.
• Do not pass any session tokens in URLs
• Clear sessions on logout
• Sessions should expire in a reasonable amount of time.
• Sanitize any input you are getting.
  • Sanitizing is also called encoding. Whenever there is data you are taking from users like contact form message or anything sanitize it to prevent XSS, SQLi and which could lead to more vulnerabilities.
• Any invalid input should be handled with exception handlers without raising any error.
• Check for known bad ciphers (RC4), cryptographic hash functions (MD5) and insecure random number generation.
  • When generating any tokens or whenever you are generating random numbers use secure random generating libraries or modules like a secret in python. Using default random generators is not advisable.
• All sensitive user and system actions are logged with the following: Where, What, When, Who, How.
• Use updated dependencies and check for the version change log to understand what kind of vulnerabilities that application is prone to.
• Use parameterized queries or prepared statements when taking input for the database.
  • A parameterized query (also known as a prepared statement) is a means of pre-compiling a SQL statement so that all you need to supply are the “parameters”. Instead of constructing query every time you want to work with database use parameterized queries for which the query will already be there you just need to pass parameters.
• While working with the loops maintain a counter and break the loop once it reached to maximum count which will avoid DoS attack.
• Parse JSON or XML files from only known hosts.
• Always send sensitive data over a secure channel.
• Never use defaults like default username and password, configuration.

If you guys liked it share it and if I missed anything there’s always comment section. Don’t forget that.