The low-no-code series – Synopsys: Don't code 'scaffolding interacts' without a hard hat
The Computer Weekly Developer Network gets high-brow on low-code and no-code (LC/NC) technologies in an analysis series designed to uncover some of the nuances and particularities of this approach to software application development.
Looking at the core mechanics of the applications, suites, platforms and services in this space, we seek to understand not just how apps are being built this way, but also… what shape, form, function and status these apps exist as… and what the implications are for enterprise software built this way, once it exists in live production environments.
This piece is written by Tim Mackey in his role as principal security strategist at the Synopsys Cybersecurity Research Centre – Synopsys is known for its its work in silicon chip design, verification, IP integration and application security.
Mackey writes as follows…
The business risk associated with software supply chains is just as present within the low-code and no-code world as it is with more traditional development paradigms such as containers and serverless.
Each of these paradigms assumes that the provided framework is built upon a secure foundation and that there are no spurious capabilities contained within the framework that might impact regulatory compliance.
Using the container world as a baseline, numerous reports highlight the potential for malicious code, such as crypto miners, to be present within a container image. If there isn’t an understanding of the precise contents of that container image, any deployment referencing it opens the door to multiple cyber-threats.
This is one reason why software supply chains are top of mind within cybersecurity teams.
Scaffolding interaction to 3rd-party APIs
One thing 2021 taught us about software is that supply chains are complex and that attackers consistently find weaknesses in the trust we place in our development paradigms. This then creates a paradigm where a citizen developer might know the data privacy requirements for their application but is unaware that the scaffolding interacts with third-party APIs in ways that violate the regulatory requirements which users of the app expect. An example of such a scenario can be seen with CPRA (California Rights Privacy Act) which defines new classes of PII (Personally Identifiable Information) and data transfers that a low-code and no-code framework compliant with CCPA (Californa Consumer Privacy Act) might not properly handle.
Organisations investigating in a LC/NC solution should include as part of their vendor selection process:
- A comprehensive security review that aligns with common security frameworks such as NIST 800-218, Secure Software Development Framework
- A vendor-supplied Software Bill of Materials (SBOM) to describe the complexity of their software supply chain
- A review of data transfer practices and API usage to determine the regulatory impact of data manipulation
- An understanding of what SLAs for patches related to vulnerability management efforts
The bottom line, it’s still code
While LC/NC enables a simpler development paradigm for developers and citizen developers, there is still code powering the application and if the framework provider isn’t equipped to manage the risks associated with that software, then it’s the consumer of that framework who ultimately bears the risk.
Free image: Wikimedia Commons