Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week, a remote/hybrid work special: Bribes to relocate you, Fridays are forgotten, and big tech firms stop building offices. (more…)
Atlassian today outlined its strategy to increase the appeal of the Bitbucket continuous integration/continuous delivery (CI/CD) cloud service among enterprise IT organizations. Atlassian said it plans to focus on four core pillars: Performance, management, extensibility and security and compliance, starting with an update scheduled for the third quarter.
Dan Tao, head of engineering for Bitbucket Cloud and Compass at Atlassian, said the overall goal is to make it simpler to use the Bitbucket Cloud service running on the Amazon Web Services (AWS) cloud at scale as organizations increase the rate at which they build and deploy software.
Atlassian is still supporting the Bitbucket Server and Data Center editions of the platform, but it’s apparent more organizations are shifting software development to the cloud, he noted. Atlassian is now moving to not only simplify migrations to the cloud by, for example, providing a Bitbucket Cloud Migration Assistant tool, but it is also moving to ensure applications can be developed at scale.
Achieving that goal includes making use of a more advanced diff algorithm that is four times faster in larger DevOps environments, he added.
Other planned enhancements include the ability to execute CI/CD workflows via Bitbucket pipelines, the ability to reuse multi-step pipelines across repositories, tighter administration integration with other Atlassian applications, the ability to encrypt data at rest and integration with the Snyk tool for discovering vulnerabilities in software to improve security.
Finally, the Bitbucket Cloud service will also soon support Bitbucket Mesh, a distributed storage capability that is already employed in Bitbucket Data Center.
Overall, Atlassian sees the migration to the cloud as a means to not only make DevOps workflows more accessible to a wider range of organizations, but also give organizations that have already invested in DevOps the opportunity to streamline those processes, said Tao.
Many DevOps teams today maintain complex platforms with custom integrations that they need to maintain and support. Atlassian provides DevOps teams the option to either employ an integrated platform or use connectors it has created as part of the Atlassian Open DevOps framework to make it simpler for teams to use whatever mix of tools they prefer, he added. In either case, the total cost of maintaining a DevOps environment can be significantly reduced, said Tao.
It’s not clear to what degree organizations that have already invested in DevOps are considering replacing their existing CI/CD platforms. However, as the pressure to accelerate the rate at which software is built and deployed steadily increases, the pressure to further automate DevOps workflows also builds. At the same time, DevOps teams are now being asked to integrate security gateways that require additional custom integrations within legacy platforms that they would need to support alongside existing integrations.
At the very least, more organizations than ever are weighing their DevOps options. The issue, of course, is that the total cost of switching out DevOps platforms is not inconsequential given the current dependency on existing workflows.
Recent security incidents have the industry buzzing about the lack of knowledge about code dependencies, attacks on the software supply chain, software bills of materials (SBOM), digital signatures, provenance, attestation and the like. The fact is, every time a new vulnerability appears a lot of time and effort is required to detect not just when, where and how the vulnerability occurred, but also to measure the real impact on the applications and services that are running in our environments.
What if we had a way to enumerate all the software components we used and produced that could be distributed and consumed easily? This is the problem SBOMs are trying to solve.
An SBOM is simply an artifact containing a comprehensive list of package dependencies, files, licenses and other assets that, together, make up a piece of software. Think of an ingredients list, but for software.
The NTIA defines an SBOM as a formal record that contains the details and supply chain relationships of various components used in building software. These components, including libraries and modules, can be open source or proprietary, free or paid and the data can be widely available or access-restricted.
This concept is nothing new, and bills of materials (BOMs) are a common, existing part of industrial processes. They are very similar to a list of ingredients, although a BOM usually includes the concept of hierarchy, as well. Every component is broken down into a list of subcomponents, each of which also includes their own BOM.
In SBOMs, the pieces are commonly abstract libraries, modules, binaries, compilers, files, etc., and they usually include licensing information (Apache 2.0, GNU, BSD, etc.) and additional metadata.
SBOMs might seem new, but the open source community realized the need for such a thing and created SBOMs more than 10 years ago. The Software Package Data Exchange (SPDX) standard was created in 2010 to communicate SBOM information including components, licenses, copyrights and security references.
In recent years, the issue has come to the fore due to the increase of attacks related to the supply chain. Here’s a short timeline.
And this is just the beginning. 2022 is becoming a turning point in how the industry is approaching SBOM and software supply chain security challenges.
An SBOM applies to any software component, either external or internal, open source or proprietary files, packages, modules or shared libraries used in the construction of software products. This includes firmware and embedded software, too. Hardware might take part in the distribution or execution of software (network equipment, cryptographic devices, chips, etc.) but is not considered part of an SBOM, although standards like CycloneDX support devices as a type of component.
In an ideal world, every software company would attach an SBOM to each deliverable, and everyone would have full visibility into the components used in the software. That would enable knowledge of exactly which vulnerabilities are impacting that software.
But we are not in that ideal world.
● Development dependencies. Every time a developer includes a third-party dependency (either open source or an internal component), it is often adding transitive dependencies – the modules or packages that the dependency itself is using. So, a detailed SBOM would enable visibility into those transitive dependencies, as well.
● Software applications or packages. When an application is distributed, the SBOM would help the consumer quickly identify the application version, helper tools that are included in the package and all the pieces that were involved in the build process. This makes it much easier to identify vulnerabilities or troubleshoot issues that might be caused by buggy software dependencies.
● Container images. Container images are basically a filesystem composed of a base image distribution plus a set of additional packages and components added during the build process.
● Hosts. Hosts include, for example, virtual machine appliance images, an AWS AMI and the like. The SBOM would include the base operating system type, vendor, version and a comprehensive list of each package installed in the host, either from the base operating system (e.g., the Linux distribution) or manually deployed from external sources.
● Hardware devices. Examples include a firewall, an IoT device or a mobile phone that is running software.
SBOMs should capture any and all multi-level dependencies. So, for example, if package libfoobar-1.5.3-r3-u8 is part of the SBOM, it should also include each package name, version, license, etc. used to assemble libfoobar-1.5.3-r3-u8, and the components for each of these, resulting in a multi-level tree where each node is decomposed into its dependencies.
It is also important to point out that every time one of these assets changes—every release of a product or even each build—a new SBOM should be created to match the changes for that version.
You need an SBOM for the same reason you need a list of ingredients for food. You can check for the presence of allergens, the presence of animal-based substances (for vegans), chemical preservatives, etc. Certainly, you can eat food without checking the list of ingredients, but you are assuming some risks. The same applies to software: It might be fine to use a dependency for a quick test in a sandbox environment, but you definitely want to know what’s inside when deploying critical services to production or delivering software in environments with strong compliance regulations.
Without an SBOM, you don’t have that visibility. A piece of software becomes an impenetrable black box with respect to the packages and libraries that are used to assemble it.
The availability of an SBOM for third-party dependencies makes it easier to build an SBOM for your software by simply adding your own ‘ingredients’ to the existing list of dependencies. Of course, your software can also be the input or dependency of a more complex product, and consumers might demand the presence of an SBOM as part of their supplier’s requirements.
Knowing which licenses are necessary for the different software pieces is also very important. Otherwise, distributing software using third-party libraries under multiple license types might break the usage terms or force you to make source code public, which can be inconvenient and even get your company into trouble.
Finally, the SBOM is a key element of the vulnerability scanning process. Provided that you have an accurate SBOM and reliable and updated vulnerability feeds from different vendors and sources, it is pretty straightforward to find which vulnerabilities are present in the software. Without an SBOM, the vulnerability scanning software needs to compute and guess; making its own inaccurate version of an SBOM, which might be quite tricky or even impossible for some components.
A good SBOM should allow organizations to answer questions like, “Am I vulnerable to the CVE-2022-22965 (Spring4Shell) vulnerability?” Exploiting this vulnerability requires a set of conditions to happen simultaneously in the host or container running the exploitable Java package:
● Using SpringCore versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19 or older, unsupported versions
● Using JDK 9 or higher
● Running Apache Tomcat as the Servlet container
● Having the library packaged as WAR
● Using the spring-webmvc or spring-webflux dependency
Most of these conditions can be checked for in the contents of a comprehensive SBOM, making it easier to assess the risk in your environments by focusing on fixing the exploitable applications first.
Currently, generating SBOMs is complex because there are multiple competing standards, distributions, etc. that make adoption slower than desired.
Many tools exist that can help you create an SBOM for a piece of software. Before you even consider producing an SBOM, it is critical that the build process is completely automated (Level 1 in the SLSA framework) and SBOM creation is integrated as part of the build pipeline.
Next, these are some example executions and outputs of open source tools and the corresponding SPDX or CycloneDX (truncated) SBOM, which are two of the most common standards.
Syft can generate an SBOM in SPDX or CycloneDX format from a filesystem or container image, and it is embedded in Docker by default using the docker sbom command.
$ syft neo4j:latest
✔ Parsed image
✔ Cataloged packages [376 packages]
NAME VERSION TYPE
CodePointIM 11.0.15 java-archive
FastInfoset 1.2.16 java-archive
…
util-linux 2.36.1-8+deb11u1 deb
wget 1.21-1+deb11u1 deb
zlib1g 1:1.2.11.dfsg-2+deb11u1 deb
zstd-jni 1.5.0-4 java-archive
zstd-proxy 4.4.8 java-archive
When using the -o flat to set the output to spdx-json format, it will produce a document like:
$ syft -o spdx-json neo4j:latest
✔ Parsed image
✔ Cataloged packages [376 packages]
{
“SPDXID”: “SPDXRef-DOCUMENT”,
“name”: “neo4j-latest”,
“spdxVersion”: “SPDX-2.2”,
“creationInfo”: {
“created”: “2022-06-23T10:09:26.751733Z”,
“creators”: [
“Organization: Anchore, Inc”,
“Tool: syft-0.48.1”
],
“licenseListVersion”: “3.17”
},
…
“packages”: [
{
“SPDXID”: “SPDXRef-fd9f083cc189cf0c”,
“name”: “CodePointIM”,
“licenseConcluded”: “NONE”,
“checksums”: [
{
“algorithm”: “SHA1”,
“checksumValue”: “50a6f2c46702b14cb129aac653d9abfcdc324363”
}
],
“downloadLocation”: “NOASSERTION”,
“externalRefs”: [
{
“referenceCategory”: “SECURITY”,
“referenceLocator”: “cpe:2.3:a:oracle-corporation:CodePointIM:11.0.15:*:*:*:*:*:*:*”,
“referenceType”: “cpe23Type”
},
…
{
“referenceCategory”: “PACKAGE_MANAGER”,
“referenceLocator”: “pkg:maven/CodePointIM/CodePointIM@11.0.15”,
“referenceType”: “purl”
}
],
“filesAnalyzed”: true,
“licenseDeclared”: “NONE”,
“sourceInfo”: “acquired package info from installed java archive: /usr/local/openjdk-11/demo/jfc/CodePointIM/CodePointIM.jar”,
“versionInfo”: “11.0.15”
},
{
“SPDXID”: “SPDXRef-80979ce84b1617b2”,
“name”: “FastInfoset”,
“licenseConcluded”: “NONE”,
…
},
…
],
“files”: [
{
“SPDXID”: “SPDXRef-9e950849d3fbc974”,
“comment”: “layerID: sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be”,
“licenseConcluded”: “NOASSERTION”,
“fileName”: “/bin/bash”
},
{
“SPDXID”: “SPDXRef-d1fd1bc48eedeaba”,
“comment”: “layerID: sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be”,
“licenseConcluded”: “NOASSERTION”,
“fileName”: “/bin/cat”
},
…
],
“relationships”: [
{
“spdxElementId”: “SPDXRef-a124711c55c5b5ec”,
“relationshipType”: “CONTAINS”,
“relatedSpdxElement”: “SPDXRef-9f73084aac22b0b3”
},
{
“spdxElementId”: “SPDXRef-a124711c55c5b5ec”,
“relationshipType”: “CONTAINS”,
“relatedSpdxElement”: “SPDXRef-23989aa2a193ea3d”
},
…
]
}
This not only includes the packages but also the files in the image, relationships between the elements, licensing information and more.
The Node.js package cyclonedx/bom allows you to generate an SBOM from a Node project in CycloneDX format. An example output when generating the SBOM from github.com/fastify/fastify looks like:
$ cyclonedx-bom
$ cat bom.xml
<?xml version=”1.0″ encoding=”utf-8″?>
<bom xmlns=”http://cyclonedx.org/schema/bom/1.3″ serialNumber=”urn:uuid:be53de33-6897-49ca-855d-926383866c21″ version=”1″>
<metadata>
<timestamp>2022-06-23T10:03:17.018Z</timestamp>
<tools>
<tool>
<vendor>CycloneDX</vendor>
<name>Node.js module</name>
<version>3.10.1</version>
</tool>
</tools>
<component type=”library” bom-ref=”pkg:npm/fastify@4.1.0″>
<author>Matteo Collina</author>
<name>fastify</name>
<version>4.1.0</version>
<description>
<![CDATA[Fast and low overhead web framework, for Node.js]]>
</description>
…
</component>
</metadata>
<components>
<component type=”library” bom-ref=”pkg:npm/%40fastify/ajv-compiler@3.1.0″>
<author>Manuel Spigolon</author>
<group>@fastify</group>
<name>ajv-compiler</name>
<version>3.1.0</version>
<description>
<![CDATA[Build and manage the AJV instances for the fastify framework]]>
</description>
<licenses>
<license>
<id>MIT</id>
</license>
</licenses>
<purl>pkg:npm/%40fastify/ajv-compiler@3.1.0</purl>
<externalReferences>
<reference type=”website”>
<url>https://github.com/fastify/ajv-compiler#readme</url>
</reference>
<reference type=”issue-tracker”>
<url>https://github.com/fastify/ajv-compiler/issues</url>
</reference>
<reference type=”vcs”>
<url>git+https://github.com/fastify/ajv-compiler.git</url>
</reference>
</externalReferences>
</component>
…
</components>
<dependencies>
<dependency ref=”pkg:npm/fast-deep-equal@3.1.3″/>
<dependency ref=”pkg:npm/json-schema-traverse@1.0.0″/>
<dependency ref=”pkg:npm/require-from-string@2.0.2″/>
<dependency ref=”pkg:npm/punycode@2.1.1″/>
<dependency ref=”pkg:npm/uri-js@4.4.1″>
<dependency ref=”pkg:npm/punycode@2.1.1″/>
</dependency>
<dependency ref=”pkg:npm/ajv@8.11.0″>
<dependency ref=”pkg:npm/fast-deep-equal@3.1.3″/>
<dependency ref=”pkg:npm/json-schema-traverse@1.0.0″/>
<dependency ref=”pkg:npm/require-from-string@2.0.2″/>
<dependency ref=”pkg:npm/uri-js@4.4.1″/>
</dependency>
…
</dependencies>
</bom>
Snyk’s snyk2spdx tool leverages Snyk’s open source API to create an SBOM from your code repositories. Unfortunately, at the time of writing, this repository is outdated and unmaintained.
There are also a number of online tools that allow importing different formats or manually adding components to the SBOM definition and then downloading it. The NTIA also published the “How-To Guide for SBOM Generation“, a collection of simple instructions and guidance on how to generate an SBOM. It is interesting that the guide includes the concept of “completeness assertion” for cases where the dependencies of some components are missing.
Ideally, the vendor of a product should tell us every component and provide it in a digitally signed document to prevent tampering or modifications. But we are still far from this holy grail, and there aren’t many vendors producing and providing this information. It’s a complex process involving multiple tools and pieces, and there are multiple standards for SBOM distribution.
In an ideal world, every vendor would provide a 100% accurate, comprehensive, digitally-signed bill of materials in a common standard. But in the real world, we usually need scanning tools that can produce a ‘guessed’ bill of materials. This is harder, as many components are opaque and it is difficult to discover the dependencies or libraries used during the build.
Still, scanning is necessary, as the SBOM from the vendor might be wrong. The vendor’s build process might be compromised, so some components might be intentionally omitted from their SBOM, which brings us to the following question: Can the SBOM be wrong or inaccurate?
Yes. The quality of an SBOM depends on the quality and automation of the process that builds the SBOM.
It is easy to produce the root level (like the version and details of the software you are directly building) and the first level of dependencies (packages and third-party libraries). It becomes more difficult to do so for transitive dependencies and even harder as you navigate deeper in the tree. Many components might not provide their own SBOM and detecting dependencies can be complex or just plain impossible, like in statically linked binaries with stripped information.
Even with a perfect toolchain and perfect SBOM information during the build phase, an attacker could tamper with the contents of the SBOM (i.e., modify the companion file or artifact at rest) to hide the fact that it contains vulnerable or malicious components. A consumer would then retrieve the modified version of the SBOM and miss these dangerous components.
A common, recommended practice is adding a digital signature to the SBOM artifact to make sure the consumer can verify its authenticity and integrity.
Even worse, it is possible that an attacker could compromise the build pipeline itself and modify the process of creating the SBOM, which would result in a digitally signed but altered list of components.
From a scanning tool perspective, a software component is usually a black box, or the amount of information that can be obtained from analysis might be quite limited, as most of it (like pom.xml or go.mod files) is available during a build but removed in the final deliverable.
An appropriate simile would be analyzing food in a laboratory versus having the list of ingredients from the producer. Analysis or scanning would produce quantitative data (what is observed in the box) versus the provided SBOM which can contain qualitative data and that can be lost or invisible to an analysis.
To minimize the risks of poor quality SBOMs or attacks, it is recommended that organizations use scanning solutions even in the presence of vendor-provided SBOMs.
A vulnerability is a weakness or flaw that an attacker can exploit to bypass security boundaries, get access to a system and more. They are a typical way to attack or compromise the software supply chain.
To find vulnerabilities in a piece of software (or in a running host, a container image, etc.), you need something that matches “known” vulnerabilities with the set of components in your software. This is called vulnerability scanning. And it’s where the SBOM comes into play, as it contains a comprehensive list of packages and versions composing your software.
Then, another big question arises: Where do the known vulnerabilities come from? (Note that vulnerabilities need to be known in advance, you cannot detect an unknown flaw.) Researchers and hackers discover them and they end up in vulnerability databases that can be consumed by humans or computers. There are two main sources for vulnerabilities: Vendors and independent providers.
Vendors can provide feeds for vulnerabilities in their products, like major Linux distributions or package repositories like Go, npm, etc. Vendors have good context around how the vulnerability impacts the product. However, they might also be biased in regard to severity.
Independent providers like NIST, Mitre, the Open Source Vulnerabilities Database and commercial offerings like Snyk and VulnDB collect, analyze and provide information for vulnerabilities. The drawback is the score is objective, without a specific context of how the vulnerability might apply to different products. In some cases, vulnerabilities might not even impact a vendor-specific product version because it is forked or the patch is backported.
Consuming vulnerability feeds can be challenging because different formats and standards exist for vulnerability information exchange, like:
● Red Hat OVAL – An XML format used for Red Hat Enterprise Linux, Openshift, and other Red Hat products and also available for Ubuntu.
● Different JSON feeds like the Debian Security Tracker.
● APIs like OSV allow querying for specific open source package versions.
● Security advisories meant for humans but not for automated processing, like Gentoo security.
● NVD CVE JSON v5.0, an attempt to create a standard CVE format.
● Common Security Advisory Framework (CSAF) – Standardized automated disclosure of cybersecurity vulnerability issues.
● Vulnerability Exploitability eXchange (VEX), which has been implemented as a profile of CSAF.
VEX is interesting, as it allows vendors to provide a kind of ‘negative’ security advisory that says, for example, that a certain vulnerability does not apply to a component because the submodule in the package is not even used in the product.
Another source that can help prioritize vulnerabilities is the CISA’s Known Exploited Vulnerabilities catalog (KEV), an updated list of vulnerabilities with assigned CVE ID, reliable evidence of being actively exploited in the wild and clear remediation (such as a vendor update).
The following diagram describes the full vulnerability management flow:
A typical flow is comprised of a scanning tool that is capable of creating an SBOM by analyzing a container image, host or workload, or directly by consuming a pre-computed SBOM (or both!). The scanning tool then matches known vulnerabilities from different sources (usually the vendor-provided sources for the corresponding Linux distribution, plus generic sources like NVD to report the list of vulnerabilities impacting the software.
You can see an example of matching the Kubernetes SBOM (which is publicly available for each version) with known vulnerabilities from OSV using the spdx-to-osv tool.
The list of detected vulnerabilities can be curated and prioritized with additional information, like VEX (not exploitable vulnerabilities) from the vendor, KEV list or risk spotlight information from Sysdig, which can detect the packages effectively loaded during the execution of the workload. This filters out the packages that are inside a container image but never executed, so they are not exploitable.
Even though there is a lot of buzz around supply chain security and an ever-growing set of tools and products, many of these tools generate SBOMs by analyzing the components and guessing the dependencies.
The optimal approach to generating an SBOM on every upstream component still requires tailor-made solutions for most cases. This translates into incomplete or inaccurate SBOMs, not to mention the different existing formats (CycloneDX, SPDX, SWID) and lack of a standardized distribution mechanism, making wider consumption of SBOMs pretty difficult.
Another problem to consider is that the limitations in the SBOM propagate to vulnerability scanners. For example, a missing package can result in a false negative (an existing vulnerability not being reported) and applying a patch on a custom package version can result in a false positive. In general, any package customization which doesn’t result in a version reflected in vulnerability databases might cause a false positive/false negative issue. And there is no single provider for vulnerability information, nor a single exchange standard. Ideally, every vendor would provide their own source of security advisories, and VEX to allow flawless identification of the existing weaknesses.
An SBOM is a key element in securing the software supply chain and fundamental for vulnerability matching and management. It is becoming more important as software consumers and governments are raising the collective bar on security requirements and software quality for their providers.
At the time of writing, there are still different competing standards, a plethora of tools and a lot of uncertainty; most of the actors are still struggling to get there. But the general consensus is that we need to secure the supply chain, converge on common standards, and make the SBOM an essential part of the build process.
An interesting initiative to follow up to start securing the supply chain is the SLSA framework, which introduces different levels of maturity in the software supply chain, so you can start from nothing and progressively implement different mechanisms to be as resilient as possible, at any link in the chain.
More than a year after the massive SolarWinds cyberattack, targeted companies continue to feel its ramifications in both reputation and financial cost. Moreover, the global software supply chain remains vulnerable to severe attacks, whether from a hostile nation-state like Russia–now increasingly in the cybersecurity spotlight due to fears of retaliation due to U.S. sanctions–or from any other cybercriminal party.
As long as the world continues to choose fast over secure, nothing is safe. No one knows how many potential backdoors the SolarWinds attack alone created, which could allow the persistent presence of malicious actors on a seemingly infinite number of networks; nor do we know when the next attack will happen with potentially more dire consequences. For example, six months after the discovery of the Log4j vulnerability and its associated patches, we know that networks and products all over the world remain unpatched, vulnerable and exploitable in all sorts of companies both big and small.
This must change. And that change must start from the inside out; meaning programmers, developers and DevOps teams should start building code more securely in the first place. That also means that those who use cloud services, third-party black box software or the services of hub companies, whose networks connect both suppliers and customers, should better understand how code development affects security. This increased focus on the underlying technology itself will not completely prevent attacks, but it will reduce the number of attacks.
There are signs that the industry is moving in this much-needed direction—or that there are at least more discussions about it. The White House recently hosted meetings with technology experts focused on this very topic. And this spring, the SEC announced that it may begin requiring some companies to report cyberattacks within four days and also provide details about their cybersecurity posture. This increased government attention is raising awareness and could also open the door to regulations, or at least universal best practices for coding protocols. But regardless of eventual, still-hypothetical regulation, developers—and cybersecurity professionals at hub companies—should give serious thought to the process they use to securely build their products.
Of course, an oft-recommended solution is to move to open source software (OSS). Although open source code is still vulnerable to attacks, the processes and practices involved in creating OSS code are transparent, which goes a long way toward crippling the ability of bad actors to conceal themselves. But such an approach will never work on a large scale in the private sector as there is no way to prevent programmers from simply copying others’ novel code, leaving no way to protect intellectual property among software developers.
However, there are other steps that could be nearly as effective, including integrating security features and testing into development tools and processes. For example, making gray and black box penetration testing a routine part of the software production process would go a long way in helping find vulnerabilities in the code that outsiders could find and access. Ideally, developers could then also remedy or repair these vulnerabilities. Also, assessing security at every step of the development process could give crucial insights into vulnerabilities before they are discovered in the wild by malicious actors.
Implementing other methods to spot security flaws in code, including in open source code, would also help. Using innovations like code-signing would alert developers if any changes were made to the code before they use it, helping to spot hackers or backdoors before the code is implemented into the product. In addition, developing better source code scanning technology is important for flagging vulnerabilities. Developers should also undergo training focused on building a product with a secure life cycle and implementing security protocols for merging and accessing the product code; this could prevent cyberattacks from occurring as a result of a faulty (or nonexistent) SDLC process—the same way an electrical engineer couldn’t design a building electric plan without formal training and certification and participating in regular continuing education and recertification.
CISOs and IT professionals also have an active role to play. They need to evaluate the security of their products’ underlying code , taking full advantage of the software bill of materials (SBOM), which lists all components of software (and that could soon be required by law) but that is only one side of it. This needs to be coupled with measures like code signing, scanning for flaws and keeping an updated list of components to spot newly-published weaknesses and vulnerabilities in libraries and frameworks. And it is increasingly important to make sure that contracts with software service providers specify they are adhering to secure development practices.
With the world on high alert and the private sector especially vulnerable to state-sponsored cyberattacks, there has never been a better time to focus on building more secure code. This does not mean that all of the other aspects of cybersecurity—including threat intelligence, incident response plans and hiring and retaining talented professionals—will be any less important. But if the code underlying the software can itself become more secure, these attacks could become fewer in number and their damage less far-reaching.
A survey of CEOs and IT professionals involved in application testing finds a significant gap in terms of how acceptable it is to release software that has not been properly tested.
The survey, conducted by the market research firm Censuswide on behalf of Leapwork, a test automation platform provider, polled 480 CEOs in the U.S. and the United Kingdom (UK) from organizations with more than 500 employees and 480 heads of quality assurance, testers, release and delivery managers and site reliability engineers (SREs).
A full 85% of the CEOs in the U.S. and 69% in the UK said it’s acceptable to release software that hasn’t been properly tested, as long as patches are tested and applied later. Less than half of the IT professionals surveyed (49%) agreed. A full 94% of CEOs also said they’re confident the software released is tested regularly.
However, 79% of the IT professionals admitted that as much as 40% of software goes to market without sufficient testing. As a result, 68% of UK and 52% of U.S. IT professionals said their teams spend five to 10 days per year patching software.
The survey also made it clear that everyone involved is well aware of the risks that lack of testing creates. Nearly every CEO (95%) is concerned about losing their job in the wake of a software failure. Slightly more than three-quarters of the IT professionals (76%) surveyed have the same fear.
More than three-quarters of CEOs (77%) also noted that software failures have harmed their company’s reputation in the last five years.
Many organizations today assume that Agile development and DevOps best practices will enable them to apply patches quickly in the event an issue arises. The trouble is, in the absence of sufficient testing many of those organizations are essentially experimenting on end users.
Leapwork CEO Christian Brink Frederiksen said the primary reason so much software is not being properly tested is that most organizations continue to rely on manual testing processes that can’t keep pace with the rate at which applications are now being developed; one major factor is the use of low-code and no-code tools.
Of the IT professionals at organizations that release insufficiently-tested software, a full 40% cited underinvestment in test automation as a factor, with only 43% of respondents using some type of automation. Other reasons cited for the lack of appropriate testing included lack of time (34%) and increased rates of deployment (29%).
Just over a third of CEOs (34%) and about four in 10 testers (42%) whose companies use or develop in-house software that goes to market without being tested also cited a lack of available skilled developers. More than a third of CEOs (34%) also cited underinvestment in testing personnel.
At a time when more organizations than ever are dependent on software to drive digital business transformation initiatives, it’s apparent that an application testing crisis is imminent. The only thing left to be determined is how catastrophic the fallout will be because existing processes don’t scale to meet the challenge.
Fear of automation (automation anxiety) has existed since the 16th century. It has been a major driver of negative attitudes toward technology and machines (also known as technophobia). With more sophisticated low-code and no-code development solutions on the horizon, even software developers face bouts of disquietude related to their job security.
While low-code solutions have the power to improve customer experiences rapidly by automating redundant business processes, can they replace developers altogether? The following guide will attempt to peer into the future of low-code development by analyzing current trends and upcoming advancements.
Low-code describes tools, platforms, and other technologies that allow you to build applications with as little coding as possible. Many of these platforms let you build entire web or phone applications through a drag-and-drop interface.
However, most small-to-medium size enterprises use these low-code tools to build simple background services to help optimize employee workflows. Recently, we have seen the popularity of rapid software development and deployment methodologies such as Agile and DevOps.
Many businesses have begun to integrate cross-functional collaboration models to optimize these pipelines. This has spawned multidisciplinary development teams known as fusion teams. These teams often consist of a mixture of software developers and non-tech business analysts who may not have coding experience.
IT leaders have found that the best way to bridge the gap between fusion team members is through low-code development platforms. Many of these platforms have begun to roll out new features to facilitate smooth collaboration between fusion teams as well.
Low-code platforms have always been used to create rudimentary solutions to urgent business problems. However, recently, they have advanced to address new problem domains.
Microsoft Access is one of the earliest examples of a commercial no-code/low-code tool. It allows you to build databases using forms and other graphical tools. The tool was originally intended to help users build small personal databases without using SQL (or Transact-SQL). However, workers began sharing these Access-created databases among their peers.
Eventually, large companies would start building entire workflows around these databases. There are many reasons why this may become a liability for these companies. Using a fully specialized relational database management system such as Microsoft SQL or MySQL is the safer bet.
Organizations must still use the services of experienced software developers and database administrators. These professionals can ensure that databases are secure and compliant with standards such as HIPAA and the EU’s General Data Protection Regulation (GDPR).
Thus, despite Microsoft Access allowing non-technical users to create databases without any knowledge of SQL, programmers were still required to connect the dots. Low-code tools such as Access allowed business users to develop concepts and prove markets before bringing in developers to expand on the core ideas.
Developers would then remodel the data (for optimization) and build applications around these Access databases.
Today, more involved and sophisticated low-code development platforms (LCDPs) can be used to build desktop and mobile apps. We have seen low-code tools empowered by cloud-native SaaS applications, allowing users to build scalable architectures easily. These LCDPs can allow you to build custom mobile, desktop and web apps that can satisfy advanced use cases such as accepting payments or simple ones such as restricting access to certain content.
A software developer’s focus is to write code; that is their daily life. Thus, they may not have the on-the-job experience of the professionals or the use cases they write applications for. Who is more equipped to write robust medical apps than doctors and other medical staff? Who can fully sympathize with the plight of construction workers better than other construction workers?
That’s why the “citizen developers” movement has become so prominent. In fact, research conducted by Gartner revealed that over 41% of non-IT professionals customize or build their own software solutions to address business problems. Despite these statistics, businesses still need the input of developers. The problem domain has just evolved.
As sophisticated as LCDP and NCDP tools are becoming, they still have their limitations. In the future, businesses will be able to address these limitations in a couple of ways.
Machine learning and artificial intelligence will be highly influential in the direction of low-code/no-code technology. Platforms like Microsoft’s AI builder already provide a low-code approach to building machine learning-powered automated software. You can then integrate these template-built ML models into your business applications or software stack.
We have seen how they have been used in medical and veterinary communication software to automate scheduling and communications. Thus, LCDPs can be used to make machine learning more accessible to non-coders.
However, machine learning can also make low-code platforms more effective. For instance, ML-powered data mining can be used to find the latest updates and the best solutions to business problems. It will allow NCDPs/LCDPs to provide more relevant and tailor-made suggestions to citizen developers.
In the future, it may be possible to build an automation process or application by simply supplying a specification through text, a UML use-case diagram, or speech. This allows for more flexible project composition options.
Improving the user experience is one of the most important priorities of IT leaders today. Machine learning paired with low-code will help businesses rapidly address these challenges.
Eventually, business owners and non-IT staff run into problems that low-code solutions simply cannot address–at least not out of the box. In these situations, it would be best to hire a developer.
Enterprises will still require the services of professional application developers for more involved and complicated use cases. This will be the case even with machine learning and artificial intelligence powering future low-code solutions.
The truth is while business users may hold a deeper understanding of the relationship between business objects, only trained and experienced software developers can efficiently implement these concepts in code.
Thus, no-code will not bring about the extinction of the professional developer. Instead, it will facilitate improved collaborations between citizen developers and professional developers. This is especially important for medium to complex projects.
The industry’s recent trends and heavy emphasis on cybersecurity and network security are another reason why software developers will not become obsolete. For instance, many developers have found that they need to pay more attention to API security, thanks to uncovered vulnerabilities in APIs such as Log4j.
As such, they must integrate security earlier in the development pipeline to prevent any possible data leaks and breaches. Most low-code tools use APIs to build applications. Unfortunately, citizen developers cannot secure their applications the same way professional application developers can. Even as LCDPs receive security updates regularly, it may not be enough to protect business applications from future cyberattacks.
Again, this is why collaboration between citizen and professional developers is so important. Only the latter can truly ensure that business software is secured appropriately.
Future no-code and low-code tools must be able to easily promote collaboration between professional developers and non-developers. These platforms should provide relatively easy and secure ways for developers to access code to modify and extend it as freely as possible.
In most cases, software developers already have frameworks and tools that they prefer to use for their workflows. From IDEs, CI/CD automation to testing software; low-code platforms should be able to plug into or interface with these established environments and tools.
Again, this attribute is extremely important, especially with the sweeping popularity of development and delivery methodologies such as Agile and DevOps. These techniques and models require smooth collaborative action between cross-functional teams. The more flexible an LCDP, the better. We’ve seen how unnecessary programming constraints of modern LCDPs can obstruct progress in cross-functional settings. These shortcomings must be addressed. If LCDPs/NCDPs fail to do this, their existence in the market will most likely be short-lived.
We do not see low-code platforms completely deprecating professional software developers in the near (or far) future. However, they will change how developers build software. Business and job requirements for programmers will evolve too as low-code has the potential to improve collaboration between developers and non-developers.
Citizen developers can use low-code tools to model what they want for their final product before allowing experienced developers to expand and build upon these ideas. Thus, these low-code development platforms must be accessible and easier to use for citizen developers but less restrictive and more flexible for professional application developers. They must allow professional devs to code more freely. This will be the focus of low-code platform developers in the coming years.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Matt Hicks is the new Red Hat CEO, visual accessibility is in focus, and Google Cloud rolls out ARM instances. (more…)
Scribe Security today unveiled a Scribe Integrity tool that scans software artifacts to make sure they comply with IT organizations’ security policies before they are integrated into an application.
The Scribe Integrity tool authenticates open source and proprietary source code before it is uploaded into a build. It assumes that all artifacts are “guilty” until they can prove their innocence, said Rubi Arbel, CEO of Scribe Security. That approach makes it possible to ensure the integrity of the overall software supply chain is maintained in a way that doesn’t adversely impact the productivity of developers, he added.
In addition, the company launched GitGat, an open source policy-as-code tool based on Open Policy Agent (OPA) agent software that enables DevOps teams to periodically run reports that surface insights into the security posture of code residing in GitHub repositories.
Arbel said that, in time, GitGat’s reach will be extended to add support for additional continuous integration/continuous delivery (CI/CD) platforms.
The first release of Scribe Integrity addresses Node.js code and the npm package manager with support for additional types of code planned.
The Scribe Integrity tool also identifies all dependencies to enable DevOps teams to generate an accurate software bill of materials (SBOM) as each software artifact is included in the application, he noted. That’s critical because it enables developers, IT operations and cybersecurity teams to simultaneously see what artifacts, including containers, make up an application, noted Arbel. In the future, the company plans to make available a Scribe Hub that will make it easier to share insights into those software artifacts, he added.
A series of high-profile security breaches clearly demonstrated cybercriminals’ skill at injecting malware into software artifacts and compromise any application that incorporates that artifact into an application. That malware can then be activated at some later date to potentially compromise any number of downstream applications.
Those incidents resulted in a greater appreciation for DevSecOps best practices to maintain the integrity of software supply chains. The issue that DevOps teams are trying to address is how to build more secure applications without slowing down the rate at which those applications are built and deployed. As such, DevOps teams are adding tools to the application development process that make it easier for developers to scan code before it is included in an application and verify the integrity of any software component that becomes part of a DevOps workflow.
It’s unknown how long it may be before the adoption of DevSecOps best practices has a meaningful impact on application security. However, waiting to focus on security until after an application has been deployed is way too late. Cybercriminals today can discover flaws and misconfigurations in applications in a matter of minutes. As more applications are deployed, developers can find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building applications that are secure from the ground up is clearly required.
The intersection of CI/CD and network automation has grown substantially over the past few years. Network teams have seemingly reached the point in their automation and orchestration journey where it has become critical to implement a strategy to manage the testing, version control and deployment of both network changes and automation assets.
While CI/CD has grown in popularity, there are—at least on the surface—many differences in the types of pipeline implementations to which network teams want to apply the technology: Different tooling, different scenarios and different problems being solved. Despite the seeming disparities, there are some key themes that are consistent throughout most pipeline implementations. For instance:
Network teams either want to develop pipelines to better manage specific changes to the network or they want to use pipelines to better manage the testing and deployment of automation and orchestration assets like workflows or scripts. Where initially those teams may have turned to network infrastructure-as-code (IaC), a significant (and growing) number are investing in automation asset pipelines.
The trust and resources being dedicated to these pipelines is just one of a growing number of indicators that automation and orchestration solutions are maturing and moving beyond initial implementations to large-scale, business-as-usual technologies.
A close examination of recent pipeline developments provided more clarity about the respective strengths of CI/CD tooling and network automation tools for network change management and life cycle—GitLab, GitHub, Jenkins and CircleCI to name just a few. Most network teams would prefer to stick with a “right tool for the right job” philosophy, wherein the best tool for any given task can easily be integrated into an overall solution.
In this context, the “right tool” philosophy looks at pipelines and at network automation/orchestration tools to identify what they do best. Then, a strategy is developed that maximizes the benefit of both technologies. Using this approach, teams can avoid the pitfalls of trying to solve everything with one or the other, leading to a suboptimal process.
Some good current rules of thumb are based on two simple points:
By integrating both technologies into a common pipeline, network teams can get the best of both toolsets.
The example below illustrates an integrated model where network automation tools provide the engineering logic for the generation, testing and deployment of configuration changes, while the CI/CD tools (represented by the orange arrows) carry the activities through a repeated, automated process, ensuring that the changes go through a consistent path with proper version management, approvals and testing. Multiple teams have successfully implemented this model and they are beginning to iterate their solution to incorporate their unique experiences and improvements.
The widespread expectation from the industry is that, in addition to the integration of CI/CD and automation into a common pipeline, we will begin to see other indicators of maturation of orchestration and automation. Some of these are areas that are already taking shape, such as the shift in skillsets and competencies outside of traditional CLI-centric engineering toward DevOps and CI/CD skills, or the growing importance of quantifying the business impact of automation and orchestration.
Styra, Inc. today launched an authorization service based on the Open Policy Agent (OPA) software that can be invoked via an application programming interface (API).
Torin Sandall, vice president of open source for Styra, said the Styra Run cloud service will make it much simpler to embed enterprise-grade authorization capabilities within applications. Today, developers spend too much time building, maintaining and operating their own authorization platforms to manage permissions across multiple applications.
In addition to enabling developers to access pre-built OPA logic, Sandall noted the service also offloads storage and global replication of end-user permissions data to a cloud service.
The service itself currently runs on Amazon Web Services (AWS), but Styra plans to make the service available on other cloud platforms in the future, he added.
OPA makes use of a general-purpose policy enforcement engine that developers can embed within applications using the Rego language. OPA is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) and is gaining traction among cloud-native application developers. OPA provides a means to enforce compliance-as-code across a wide range of microservices that now routinely access a wide range of distributed data.
However, Styra Run should make OPA more accessible to a wider range of organizations, especially those that are looking to shift responsibility for security and compliance further left toward developers as part of a set of DevSecOps processes, noted Sandall. Developers that don’t have a lot of compliance expertise can now rely on a cloud service that enables them to focus more of their time and effort on writing code, he added.
The arrival of Styra Run also comes at a time when more organizations are reviewing their software supply chain processes in the wake of a series of high-profile security breaches. It’s not clear to what degree compliance and cybersecurity teams have developed an appreciation for OPA, but as more organizations embrace compliance-as-code, the pressure on those teams should decrease as those applications are inherently more secure than legacy applications.
There will, of course, be some developers that prefer to embed OPA into applications themselves, but a cloud service accessed via API will be the path of least resistance for most developers building software-as-a-service (SaaS) applications, said Sandall. The issue may simply be making developers aware that another low-latency option exists; one that doesn’t require them to deeply master the Rego programming language for the sole purpose of achieving compliance, he added.
Regardless of approach, the general expectation going forward is that applications will more easily be able to meet a wide range of compliance mandates without requiring IT teams to deploy and maintain dedicated compliance infrastructure. As such, there may soon come a day when any application that doesn’t use some type of compliance-as-code framework will simply be rejected out of hand.