How DevSecOps Empowers Citizen Developers

By 2025, total global data creation will reach 181 zettabytes. For enterprises, that data is an asset, allowing them to leverage a variety of technology platforms to create highly personalized customer experiences that engender loyalty and attract new business. However, these experiences are dependent on cloud infrastructures using shared security modes. That’s where the risk lies, and it’s increasing as technology grows to incorporate a new army of citizen developers using low-code and no-code platforms.

**Understanding and Overcoming the Inheritance Mindset **

Gartner estimates that by 2025, 70% of enterprise applications will be built from low-code and no-code platforms such as Salesforce and ServiceNow. Responding with an inheritance-based mindset is a sure way to set more than two-thirds of enterprise apps up for failure.

“Inheritance mindset” is an apt descriptor for the problems plaguing infrastructure. It brings to mind a rich, spoiled children who are entirely dependent on the work done and people who came before them. That’s not a good way to build a legacy, and it’s an equally bad way to build a system.

When you have a legacy mindset, you assume that the infrastructure is set. The platform is safe, and the security is built in. Trust is assumed simply because the technology was there before the administrator.

That inheritance mindset plagues low-code and no-code platforms. Users rely on the safety of a platform to carry them through an entire enterprise infrastructure. Instead, the security of that platform should apply only to that platform.

Let’s say Salesforce developers create an automated assignment program for new leads. They use it within Salesforce for internal assignments, and it’s fine. They can rely on the safety of the platform. They decide to expand it to improve automation. They connect that program to an external-facing CRM like ServiceNow, SAP, or Oracle. The inheritance mindset takes over: Salesforce is safe. ServiceNow, SAP or the third-party is safe.

So, Salesforce + third party = safe.

But, there’s a great deal of unknown in that plus sign. How do you safely and compliantly connect the internal program created in Salesforce to the external program created in the third-party platform? There is a lot of room for error in that single character.

And that’s only one connection. Many programs created in Salesforce touch hundreds of others. That’s hundreds of unknowns being treated like the plus sign described above by people who have little to no development experience.

The only solution is to take that development back down to earth with a return to DevSecOps principles.

**Establishing the DevSecOps Framework **

DevSecOps frameworks have been written, rewritten, and written again since the concept was created. There’s no need to reinvent the wheel when establishing them, especially when SAFECode and the Cloud Security Alliance has built six pillars:

1. Collective responsibility: Security is the responsibility of every person in the enterprise —but people can’t meet standards they don’t know. Leads should be assigned to drive cybersecurity policy and ensure it is disseminated across the enterprise.
2. Collaboration and integration: Knowledge must be shared and transferred. Half the reason that enterprises fall into the legacy mindset is that everyone who knew the old system is gone. Continuous knowledge sharing helps eliminate this issue.
3. Pragmatic implementation: Pragmatic implementation ties into the developer experience. Processes that are difficult, mundane, and unwieldy are not followed for long. Security should be baked into development practices — that is, every line of code requires a line of test. A high-performing enterprise would take that further by using a tool to automate each line of test code.
4. Compliance and development: Compliance requirements should guide the development process in a way that does not allow developers to deviate from them. A developer for a financial institution, for example, would work on a platform that is designed to be compliant with the Gramm-Leach-Bliley Act. The developer does not have to know the individual ins and outs of the act to be compliant because they are built into the platform.
5. Automation: Tasks that are predictable, repeatable, and high volume should be automated whenever possible to remove the burden from developers and reduce the risk of human error.
6. Monitor: Modern cloud infrastructures change and grow. It’s vital to keep track of it — ideally, through some form of orchestration that allows an at-a-glance view of all the various interconnections.

In a low- or no-code environment, these pillars are not as straightforward as one would expect. The people using these tools are often business experts with little familiarity with DevSecOps fundamentals.

Bringing Together People, Processes, and Technology

The use of low-code and no-code platforms can actually help close this skills gap. Employees want to learn new skills. Enterprises can support that by establishing a DevSecOps framework focusing on people, processes, and technology.

• Processes: In a zero-trust environment, low-code and no-code developers don’t have to worry about making connections that endanger system integrity because they are incapable of doing so. They have no baseline authority outside of their isolated system.
• People: A culture of accountability is different from a culture of blame. Accountability means that individuals feel comfortable coming forward with a problem or mistake because the focus is on the issue, not the person.
• Technology: Technology is the single biggest barrier to proper implementation of DevSecOps principles because it is out of the developers’ hands. They must use what the organization gives them. If that technology doesn’t work, developers will come up with workarounds that are neither secure nor safe. Essentially, the technology becomes one big shadow IT generator.

We live in an exciting time for development. More and more people have the opportunity to build software, test strategies, and improve business value. But with that comes risk. Enterprises that look at ways to offload that risk onto technology will keep their development down to earth while leaving room to explore.