DevSecOps and the development process 

DevSecOps is the practice of integrating Development activities with Security checks and Operational deployments. Traditionally, most companies’ activities are focused only on development activities as it is a part of the development process in which the impact can be clearly seen and its progress is easily measured. Thus, a majority of development resources are spent on this segment of the overall process

This unbalance can be now be seen in many software development companies complaining about internal quality assurance and operations team weakness and/or nonexistence. This usually happens by development team members taking up missing roles, albeit only partially by doing minimal unit testing and ad-hoc deployment.

This practice ends up with a few painful points prevalent in the industry:

  • There is no regression test, new changes might resurface old bugs with no one noticing.
  • Problematic hotfixes, developers with direct access to deployment often leads to hotfixes with potential security and source control problems.
  • Centralised knowledge focused on developers with many problems arising if he/she left.

The last problem combined with current vendor developer environments often leads to a project’s termination as project knowledge is not passed to successors. There is no quick fix for this problem as the heart of the issue is human resources, however, developments in automation software such as Jenkins, bamboo and DevSecOps practices can bring a positive impact at a relatively quick pace.

A good DevSecOps workflow will go through 4 steps in general:

  • Pull and build means that the last action a developer needs to do is record his/her changes to the Repository. This makes sure all changes to source codes are recorded in the Repository and that there are no ad-hoc/unrecorded changes to the binaries before deployment
  • Scan processes (eg. using SonarQube) to help the security department monitor and provide alerts.
  • Deployment process done automatically (scripted) can provide insights on how things are configured by developers and will help new developers understand the program as well as reducing configuration mistakes due to human error.
  • Lastly, the testing process should create tests that can be re-run (eg. Katalon) as part of regression done automatically by DevSecOps.

Conclusion

With these steps in mind, DevSecOps can be implemented with little investment and can potentially revitalize an organisations workflow. However, this is not the final step. The organisation must maintain continued support from the security and operations department to build on the fundamental changes set in place. Thus, it is imperative that the development process be shared between the departments to prevent relapse

About iZeno

iZeno was founded in 2003 on the principle of providing enterprises with best-in-class solutions they need to keep their business running seamlessly. With a team of 70+ innovators, in-house, we have delivered over 500 Enterprise Solutions, implemented and optimized to enable smarter insights.

Our team draws on industry experiences in accomplishing a portfolio of mission-critical applications, integrating Cloud, CRM, Data Analytics, and other leading technologies with our clients existing IT frameworks.

With a leading presence in the region, headquartered in Singapore and operation in Malaysia, Indonesia, Thailand and Philippines, no project is too complex for us, and our team is always ready for a new challenge.

Get in touch with us here.