Understanding and Overcoming the Inheritance Mindset
Gartner it is estimated 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 surefire way to set up more than two-thirds of enterprise apps for failure.
“Inheritance mindset” is an apt descriptor for the problems plaguing infrastructure. It brings to mind a rich, spoiled brat who relies heavily on the work done and the 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 security is built in. Trust is assumed only because the technology was there before the administrator.
That inheritance mindset plagues low-code and no-code platforms. Users rely on the security of a single platform to bring them across the entire enterprise infrastructure. Instead, that platform’s security should apply only to that platform.
Let’s say Salesforce developers create an automated assignment program for new leads. They use it inside Salesforce for internal assignments, and that’s fine. They can rely on the safety of the platform. They decided to expand it to improve automation. They connect that program to an external-facing CRM like ServiceNow, SAP, or Oracle. The inheritance mindset rules: Salesforce is safe. ServiceNow, SAP or the third-party is safe.
So, Salesforce + third party = safe.
But, there are many unknowns in that plus sign. How do you securely and compliantly connect an internal program created in Salesforce to an external program created on a third-party platform? There is a lot of room for error with that single character.
And that’s just 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 with little or no development experience.
The only solution is to bring that development back to earth with a return to DevSecOps principles.
Establishing a DevSecOps Framework
DevSecOps the outlines have been written, rewritten, and rewritten since the concept was created. There is no need to reinvent the wheel when they are established, especially when SAFECode and the Cloud Security Alliance built six pillars:
- Collective responsibility: Security is everyone’s responsibility in the business —but people can’t meet standards they don’t know about. Leads should be assigned to drive cybersecurity policy and ensure it is disseminated throughout the enterprise.
- Cooperation and integration: Knowledge needs to be shared and transferred. Half the reason businesses fall into the legacy mindset is that everyone who knew the old system is gone. Continuous sharing of knowledge helps eliminate this issue.
- Pragmatic implementation: Pragmatic implementation relates to developer experience. Processes that are difficult, mundane, and difficult to use are not followed for long. Security must be integrated into development practices — that is, every line of code needs a line of testing. A high-performing company goes beyond that by using a tool to automate every line of test code.
- 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, will work on a platform designed to comply with the Gramm-Leach-Bliley Act. The developer does not need to know the individual ins and outs of the act to be compliant because they are built into the platform.
- Automation: Tasks that are predictable, repetitive, and high volume should be automated as much as possible to remove the burden from developers and reduce the risk of human error.
- monitors: Modern cloud infrastructures are changing and growing. It’s important to keep track of this — ideally, through some form of orchestration that allows an at-a-glance view of all the different connections.
In a low or no code environment, these pillars are not as faithful as expected. People who use these tools are often business experts who are less familiar with DevSecOps basics.
Bringing People, Process, and Technology together
Using low-code and no-code platforms can really help close this skills gap. Employees want to learn new skills. Businesses can support that by establishing a DevSecOps framework that focuses on people, process, and technology.
- Processes: In a zero-trust environment, low-code and no-code developers don’t have to worry about making connections that compromise system integrity because they can’t. 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 dealing with a problem or mistake because the focus is on the issue, not the person.
- Technology: Technology is the single biggest barrier to properly implementing DevSecOps principles because it is out of the hands of developers. They should use what the organization gives them. If that technology doesn’t work, developers will create solutions that aren’t secure or safe. Essentially, technology is becoming a huge shadow IT generator.
We live in an exciting time for development. More and more people have the opportunity to develop software, test strategies, and improve business value. But it comes with risk. Businesses that look for ways to offload that risk to technology will keep their growth on the ground while leaving room to explore.