DEVOPSdigest

The biggest challenge in today's environment is blending security into the development process. All companies have different software development life cycles (SDLC), infrastructure, repositories, availability, deployment areas (think cloud, on-premise, hybrid), accesses, etc. Adding into this the employee side of things, we consider the impact of whether teams be in office, fully remote (and global) or hybrid. I mentioned blending because most development has already been established into the life cycle before security was introduced. The balance of slowly introducing security, ideally with the biggest impact at the smallest cost (this could be financial or time and effort), into an already established life cycle is key.

Challenge 1: What if an application is made up of many different applications?

With acquisitions being commonplace, it's likely an environment will come across a scenario where Project X (which may or may not have security built-in) will need to merge into an offering of Project Y (which may or may not have security built-in).

There are many challenges in this scenario. If security is built into these projects' life cycle, it's highly unlikely they are the same if even slightly similar. There could be no security in the life cycle or a combination.

Solution

Don't demand too much too soon. There is a lot of work ahead for these two development teams.

Understanding which offering is going to assume the core functionality role (authentication scheme, access controls for APIs, user interface, etc.) will aid in where to focus security efforts. If they are to be separate offerings and only share authorization, that should be the focus for security.

The transport and storing of secrets and access control (limiting one project to only the necessary information needed from another project) should be the priority followed by the individual project's security needs.

Challenge 2: What if one product should be compatible with many different deployments?

This scenario is common for companies that have a core product that needs to be installed on different operating systems. The functionality should be the same, if not identical, but development teams that specialize in different languages that are native to the operating system can be a challenge. This is where operating system agnostic is commonly introduced (think Java).

Java can be run on any operating system because it's actually being run in a runtime environment that's installed on the operating system. So all development teams now only need to program in Java (for the majority of the logic) and security can be added to build pipelines.

However, now the product will have many third-party dependencies that will have to be continuously updated for performance improvements, added functionality, and of course, security (think Log4J).

Solution

Understanding how each team builds their portion of the product is crucial. One team that works solely in C++ will have different requirements than a team that works solely in ObjectiveC. Work with each team to find out what process will work best for them while still achieving security objectives.

It might be that a team will need to relocate their repositories to align with the rest of the company's security practices at build time.

It might be that a team just needs to add checks to ensure no hard-coded secrets are being committed and the pipeline will take care of the rest.

There is no one-size-fits all solution when working in large environments.

Challenge 3: What if there are no security features built into the life cycle?

This is common in smaller projects but definitely not rare in large, mature projects either. Sometimes the challenge is to even get started with security where the main focus has always been delivery timelines.

Solution

The good news is that there are so many options, and you have an opportunity to test out and explore different solutions to see what works best for both the development timelines as well as security requirements. The first step would be to start with easy wins. Simply use open source tooling to scan your containers and build configurations.

These tools may not be 100% accurate or inclusive but they will oftentimes find low hanging fruit and dependency issues. It also doesn't lock you into purchasing one solution and finding that it's too slow (which affects build times), too resource-intensive, or that it's causing too much noise.

Another easy to implement solution would be adding requirements for developers to use CLI tooling to check for secrets in commits. This way it doesn't require integration within the pipeline but still can yield significant value and there are many open source options available to try out and see which one works best for your environment and development process.

There are many other challenges:

What if one product is committed to Private repositories on GitHub and another on an on-premise GitLab instance?

How can secure coding education be introduced?

Understanding the development process and the teams that work within them is essential. Frequently, introducing security is seen as a hindrance to production. This commonly leads to a division of development and security. Development and security should be a partnership. Whether they are separate teams altogether or as a collaborative effort within one team. Security should not be a continuous blocker of development progress; development should not be a continuous blocker of security progress.