devopsy.kinsta.cloud

Tag: open source

Accelerate Your SDLC With DevSecOps

DevOps has been the answer to rising software development complexity, but the granularity and multiplicity of actors, technologies and environments brings added security requirements. Moving to DevSecOps will not only help with these requirements but also accelerate the software development life cycle (SDLC).

As development projects mature, more developers get involved, the code base grows and architecture becomes more complex; consequently, the SDLC slows down. This is why Agile, microservices and DevOps have emerged—to solve this specific problem by separating big teams into smaller ones and monoliths into more nimble components.

But this granularity and multiplicity of teams, work environment, technologies, services and repositories makes integrating security even more complex. In fact, developers now face multiple SDLCs and often, the gains achieved in velocity can be nullified by security issues. You want a process that works, and preferably, a process that works fast.

This is what DevSecOps attempts to solve; adding security into DevOps actually accelerates the SDLC. Here’s why and how.

DevSecOps During the Planning Phase

The planning phase is key as it answers essential questions at the time when architectural decisions are made. Some of these decisions are relative to access control, network infrastructure and data security. For each, adding automation—and therefore, security—allows fast replication.

For access control, you can leverage infrastructure-as-code (IaC) tools (Terraform, for example) to easily define different groups, roles and permissions with code. By adding various plugins, you can even use your IaC tool to manage users on other platforms, as in GitHub. When you have all the groups, roles and permissions defined as code, you are only one commit away from access control updates.

If you need to onboard a new team member not only to, say, a specific AWS group but also to a GitHub group, instead of doing it manually in two places, you can do it “as-code” to both with minimal changes.

The complexity of organizations and the need for better security implies the need for more role-based access controls, but automation tools exist, and they are also less error-prone.

When it comes to network infrastructure, you can also use IaC, but you will also need to add a security layer on top of it to mitigate any errors in the code. As an example, you can use tfsec and terrascan on Terraform. This will scan your code statically and, based on predefined rules, generate alerts and give you advice on improving your security. If you prefer CloudFormation, use cfnlint, which even allows you to define your own security rules.

When you have your infrastructure ready, the next big thing to think about is your data. You need to put data encryption in place to make sure data is securely stored at rest. You also need to add transport layer security (TLS) for the databases to secure the traffic in transit. Besides using static code analysis tools and ready-to-use services, you can even automate your own pipeline. This is very useful when you have multiple agile teams.

Let’s take S3 buckets as an example. You could build a generic solution where the S3 event triggers a serverless function that checks the bucket’s permission. If a policy is violated, it can be fixed right away and the owner notified automatically.

Moving to Development

During the development phase, you need to address three major security areas: Code repository security, continuous integration (CI) security and container image security.

Code repository security needs to address questions around the repository access control, considering the principle of least privilege but also checking that no repository is made public by accident or that they do not contain sensitive elements, such as secrets.
With a multi-team, agile and microservices setup, you need automation to skip time-consuming and error-prone tasks but also to avoid slowing your SDLC to a crawl. We already mentioned git user management automation, but there are also a number of tools for static code analysis and secrets detection. You can even include this detection in your CI pipeline and integrate it with your alerting workflow to eliminate the risk from the origin.

CI security is often overlooked, but this is a very important element; if your CI is not set up correctly it can generate data leaks. Access to your CI needs to be controlled to give the proper permissions and access rights. Doing this manually will definitely impact your SDLC velocity so, again, there’s a need to automate. You can integrate your CI with your Git or company single sign-on (SSO) solution for authentication. For authorization, you may rely on the groups’ information provided by those SSO services.

Secrets are also critical for CI. Modern CI pipelines allow you to store secrets at a project level. Once configured, you can use it directly in the build without putting the sensitive data in clear text format. Even if you try to print the variable containing sensitive data, it will not show up. For instance, to use secrets directly from a Jenkins pipeline, you can store your secrets in a Kubernetes cluster and use Kubernetes Credentials Provider or HashiCorp Vault Plugin.

Now, let’s talk about containers. While containers have simplified the deployment, scaling and failover capabilities within the SDLC, they also introduce some challenges. If the container image has some known vulnerabilities, your containers could be exploited, and the integrity of the whole machine—or even the entire system—can be compromised. Automation is, again, the go-to solution to ensure the images you build don’t contain vulnerabilities. Some CLI-based tools like Trivy can be easily integrated into your CI pipelines.

Automation will significantly reduce your operational overhead. No more managing machines (physical or virtual), no more configuration management, no more patching. If everything is automated, that means less toil—and that means all means your SDLC is not only more secure but also faster.

Integration and Deployment

Kubernetes (container orchestration) is the current solution to streamline integration and deployment in our agile world. But Kubernetes is a complex system and comes with its own security challenges, of which the most important is secrets.

The worst thing you could do is define secrets in YAML files and store them in Git repos. You could use Kubernetes’ secrets as the single source of truth, but what about secrets created by people who don’t need access to Kubernetes? This is where a secrets manager is a good choice: It acts as a single source of truth to store your sensitive data. You will get an automated process that eliminates the toil of manual labor but also guarantees security and speed.

DevSecOps for Incident Response

Incident response playbooks are a crucial component of DevSecOps. Playbooks are a set of generalized and summarized processes that provide a consistent way of handling issues for quicker response and resolution. Learning from every incident is also part of the playbook, whether it’s a security issue or a new vulnerability.

The content can include everything from runbooks and checklists to templates, training exercises, security attack scenarios and simulation drills. The goal is simple: A set of policies, processes and practices for quickly responding to and resolving unplanned outages, thus helping teams fix online issues more quickly to reduce the size of the blast radius.

We have only scratched the surface of security automation capabilities and their potential impact on the SDLC. But it’s clear that adding (automated) security into DevOps has a positive impact on the overall velocity of the SDLC and, of course, on its security posture.

August 3, 2021
Rocky Linux Emerges as a CentOS Replacement

Rocky Linux was created to offer the community an alternative following Red Hat’s recent decision to shift its focus away from CentOS—the open source version of Red Hat Enterprise Linux (RHEL). However, the Linux distro’s popularly can also be attributed to how its creator sought to offer a superior alternative based on lessons learned during CentOS’ development—and less as a perceived backlash to Red Hat’s controversial move, said Gregory Kurtzer, Rocky Linux’s creator, who is also founder and CEO of Ctrl IQ.

“As one can probably imagine, there were a lot of lessons learned from the founding of CentOS—we did a lot of things correctly, but we made some mistakes, as well, that set into motion some of the difficulties the project went through,” said Kurtzer. “I was not—nor am I now—upset at Red Hat or anyone else. It’s important to understand that companies have a legal responsibility to do what they need to do. But I will say, this is why open source communities should not be controlled by a single company, especially if that company has a competing product to the open source project.”

In addition to applying experience gained from the CentOS project to help “recreate the initial goals of CentOS in a new project,” Kurtzer said he was prompted to create Rocky Linux following Red Hat’s decision to end-of-life (EOL) CentOS. The move “affected my company, our customers, as well as the entire industry,” said Kurtzer.

“To be blunt, my knowledge—in terms of doing it myself is severely dated. Luckily, after I made the announcement that I was considering recreating CentOS, thousands of people reached out to me wanting to be part of the project and contribute,” said Kurtzer. “From that, our development team and open source community was born.”

Additionally, CentOS Stream offers value to the community by allowing “us and others” to take part in developing the upstream Enterprise Linux standard, said Kurtzer, who added that his team will continue to debug Rocky Linux so that solutions are properly integrated into the Enterprise Linux Standard.

“The necessity was absolutely clear, so I founded Rocky Linux and the Rocky Enterprise Software Foundation (RESF),” Kurtzer explained. “Together with our contributors, sponsors and partners, we all have united for a common goal: to create an open source community that will provide us all with an enterprise operating system to stand the test of time, attrition and commercial agendas.”

Interest in the development of a CentOS alternative was strong when Kurtzer first floated the idea of the project to the community. Since its release in June, the total number of ISO downloads is 56,000, according to Rocky Linux Tier0 mirror data.

“We have zero visibility as to any other ISO downloads from any of our other mirrors, but if I were to guess, I’d say it would be about two to three times more, in total,” said Kurtzer. “When we all get a moment to breathe, it will be fun to see how many people are using Rocky Linux, and take in all the feedback the community has provided,” he said.

With this team of developers, Kurtzer said it took about seven months to build the general availability (GA) release. “We didn’t just jump right into building the operating system because the goal was to create an infrastructure where many contributors and developers can take part without putting the security of the product at risk. Building that infrastructure took about four months,” Kurtzer said. “Once the infrastructure was completed, we spent about two months building the first-release beta candidate and then spent the following month ensuring that we did everything correctly.”

July 13, 2021
Aqua Security Acquires tfsec to Advance DevSecOps

Aqua Security today announced it has acquired tfsec, an open source project that provides a static analysis scanner for infrastructure-as-code (IaC) that is designed to be integrated within a DevOps workflow.

Amer Jerbi, Aqua Security CTO, said tfsec extends the security platform the company already provides in a way that advances adoption of DevSecOps best practices. In addition, to prevent developers from misconfiguring cloud infrastructure using tools such as Terraform, the scanner surfaces examples of code that provide developers with insights into how to properly configure infrastructure.

Jerbi noted that tfsec is already integrated with Aqua Trivy, an open source tool that scans container images for vulnerabilities. Integrations with the rest of the Aqua Security portfolio will follow, added Jerbi.

Tfsec co-founders Liam Galvin and Owen Rumney will join Aqua Security as cloud engineers. The challenge Aqua Security is trying to address is the need to enable organizations to proactively prevent cybersecurity issues from arising in production environments rather than only identifying vulnerabilities that need to be fixed, said Jerbi.

The decision to acquire tfsec comes in the wake of a series of high-profile breaches when many organizations are scrambling to make sure software supply chains are secure. Cloud platforms are rife with misconfigurations mainly because developers often lack the expertise needed to ensure infrastructure is secure after they have provisioned it. Organizations are embracing DevSecOps best practices in the hopes of educating developers to assume more responsibility for application security. However, developers are not going to acquire that expertise overnight. The tfsec scanner provides a way to enforce security policies today while at the same time affording the time to teach developers how to avoid misconfigurations.

It’s unclear how many cybersecurity events arise because of cloud misconfiguration issues. The cloud service providers have adopted a shared responsibility model that makes the organization employing the cloud responsible for both the applications deployed on those clouds and for how that infrastructure is provisioned. Many developers that provision cloud infrastructure themselves within the context of a DevOps workflow often assume the cloud service provider is doing more than it is to prevent misconfigurations. Cybercriminals, meanwhile, have become very adept at scanning for those misconfigurations.

There are, of course, a lot of layers and nuances when it comes to DevSecOps. Arguably, Jerbi said, the most critical thing for most organizations is to simply get started. Tools that can be quickly and easily integrated within an existing DevOps workflow with minimal disruption are critical, Jerbi added.

In the meantime, DevOps teams should expect cybersecurity teams to become more involved in their workflows, especially as government mandates aimed at securing software supply chains become stricter. Eventually, as organizations gain confidence in the ability of their DevOps teams to secure their application environments, those cybersecurity teams will refocus their efforts on hunting for threats. In the meantime, DevOps teams would be well-advised to make those cybersecurity professionals feel as welcome as possible, given the application security mandate most of them have been given.

July 12, 2021
Best Practices for AWS Tagging With Yor
On the surface, AWS resource tags are simple, informational key:value metadata that you can assign to most AWS resources. They also have many hidden benefits, as outlined in this AWS Tagging Best Practices guide for improving cloud operations. There are six use cases author Brian Yost calls out in particular:
1. AWS console organization and resource groups
2. Operations support
3. Cost allocation
4. Access control
5. Automation
6. Security risk management
In summary, tags can simplify operational processes, improve security posture, speed up mean time to resolution (MTTR) and even save money if implemented consistently and persistently. But, unfortunately, in large organizations, that’s a tedious and often faulty process.

To help teams overcome that challenge and make the most of cloud resource tags, Bridgecrew (recently acquired by Palo Alto Networks) recently launched a new open source tool, Yor. Yor is designed to automatically add consistent, helpful tags to infrastructure-as-code (IaC) templates starting with Terraform, CloudFormation and Serverless Framework. If run locally or added to a continuous integration (CI) pipeline, Yor will add tags like git organization and repository, unique trace ID and commit modifier details to IaC resources that carry through to cloud resources. For example, with Yor, you can tag your aws_instance code block in Terraform, and those tags will show up in your running EC2 instances.

This post will explore how to leverage Yor to achieve the six tagging use cases outlined in the AWS Tagging Best Practices guide.

AWS Console Organization and Resource Groups

Using tags to organize and filter resources is the simplest and most common use case for tags. If you add tags to resources, such as EC2 instances or database resources, you can filter based on those tags.

If your AWS account has thousands or tens of thousands of resources in a region, filtering is necessary to manage those resources. For example, if you have hundreds of web servers, filter by the git_repo tag Yor added to quickly filter down to the web server(s) for your application.

In that same vein, you can set up resource groups to organize multiple resources across AWS services based on tags. For example, if you want to hunt down the VPC, EC2, internet gateway or database created by your Terraform repository, use Yor’s git_repo tag to group together multiple resources into a single resource group.

Operations Support

Yor excels at simplifying and speeding up operations support. In the words of Brian Yost, “For example, Level 1 support teams could use tags to direct workflow and perform business service mapping as part of the triage process when a monitoring system triggers an alarm.” Yor automatically tags resources with the git organization and modifiers of the cloud resource. This makes it easier to identify the right team and user to patch issues.

If you work in a GitOps organization, this is even more critical. Following GitOps best practices means all changes should be performed in the IaC template, not directly on the cloud resource. So if your security team identifies an open port 22 in runtime using policy-as-code or CSPM tools, such as Bridgecrew, Yor’s tags will make finding the owner of the IaC template easier and faster, lowering MTTR.

Yor takes this a step further. By adding the repository, file and trace tags, Yor helps teams identify not only the code owner but also the exact file and resource block that created that resource misconfiguration.

Cost Allocation

Large companies often have different profit and loss (P&L) statements for each of their business units. At the end of a reporting period, such as a fiscal quarter, finance teams allocate the expenditures made across the company to the various cost centers.

For traditional IT teams, this usually involves very broad, general estimates. For example, if two organizations share a server rack, you could allocate costs based on virtual CPU time or disk space. Once that scales into dozens of organizations and ephemeral workloads, that allocation is much more difficult. Cloud costs can be just as difficult to allocate. If you have thousands of resources across types (virtual machines, serverless, managed Kubernetes workloads, managed databases, streams, CDNs, etc.) with differing life cycles and life spans, tying those resource costs back to a cost center is difficult.

Cloud tagging simplifies that process. Assuming each team has a git organization, Yor will automatically tag resources with the git_org or custom tags can group git_modifiers into cost center tags, and AWS Cost Explorer will let you filter by those tags to easily allocate costs. You can also export those costs by tag(s) to a CSV file for import into other tools for analysis.

Yor applies those tags reliably and consistently so that finance teams don’t need to dig through different organization name versions, such as combining dev_team_one and devTeam1, or manually categorizing untagged resources.

Access Control

AWS identity and access management (IAM) policies support the ability to limit control of resources using tags. This simplifies dividing up resources by teams using complex IAM rules.

For example, if you want developers to access only the EC2 instances they provisioned, you can use the git_modifiers tag added by Yor. Yor will automatically tag resources with the git users who edited the IaC code. Then, Yor will add an AWS IAM policy to limit access based on that tag. You’ll also want to add a policy to deny actions such as ec2:CreateTags and ec2:DeleteTags so users can’t just add themselves to other resources.

This is where Checkov, an open source policy-as-code tool, can be leveraged for additional control. Yor can enrich the context for Checkov’s checks, enabling finer-grained policy control. For example, Yor will populate the user identification of whoever modified an IaC template, and Checkov can make sure that only approved team members modified the code. The following is an example of a custom check to determine that only security personnel modified CloudTrail settings.

If the git_modifier tag added by Yor is anything other than “Nimrod,” “Rotem,” or “Naor,” Checkov will show a failed policy check for that custom check for that resource.

Automation

By leveraging tags in combination with other tools, such as Lambda functions and backup plans, you can apply automation to specific resources, such as targeting resources for archive, update or deletion.

The AWS Tagging Best Practices guide uses as an example a situation where development resources are turned off during non-business hours. AWS recently released a tool called Instance Scheduler for just such a use case. It is a CloudFormation stack with a Lambda function and DynamoDB instance that automatically starts and stops EC2 and RDS instances based on a pre-defined schedule.

Instance Scheduler takes a tag with a key:value pair; for example, “Schedule” (or a custom key) as the key and the schedule as the value. The schedules can be either one of the preconfigured schedules in the DynamoDB table, like office-hours, or a custom one.

Using simple custom tags in Yor, you can tag every resource in a repository with a schedule by using environment variables such as adding the following to the Yor GitHub Action YAML file:

This results in tags being added to every resource in that IaC directory. With the seattle-office-hours tag, Instance Scheduler will turn off EC2 instances at 5:00 pm Pacific Time and on again at 9:00 am Pacific Time Monday through Friday. This saves money by stopping instances automatically during downtime.

Another popular automation use case is for backups and archival plans. AWS can automatically apply different backup plans based on the tags applied to resources, such as storage and database resources. For example, if certain organizations, such as those that process financial data, need things archived forever, but others only need one year of backup, applying backup plans can move the short-term storage to cheaper options, such as Glacier, and eventually delete them on a schedule.

Security Risk Management

The final use case is risk management. The risk level of cloud resources differs based on whether they are in test or production environments and the sensitivity of the data those resources process and hold. This is another area where you can use simple tags like git_repo to filter down to repositories for applications that deal with sensitive data. You can also leverage complex custom tags. For example, EC2 instances attached to databases with “customer” in the name will get a data_level:sensitive tag.

IT service management tools can apply higher priority to patching and updating resources with tags denoting sensitive data. This is another area where you can leverage Checkov’s graph-based checks in combination with Yor tags to assign higher severity levels to policy violations for resources with sensitive data tags or production environment tags. Assigning priority helps to focus developer attention and mitigate risk faster.

These six tagging use cases are just a few examples of how you can leverage tags to be more efficient and improve your cloud security posture in AWS. The power of Yor’s tracing capabilities enables development and operations teams to work together without requiring complex triage to find the right person and IaC templates. With Yor’s extensibility and custom tagging capabilities, we can’t wait to see what other use cases the community comes up with!
July 2, 2021
Grafana Labs Acquires k6 to Add Open Source Load Testing Tool

During its online GrafanaCONline 2021 conference today, Grafana Labs revealed it has acquired k6, a provider of an open source load testing tool.

Raj Dutt, Grafana Labs CEO, said load testing will complement the observability platform Grafana Labs currently provides based on open source Prometheus software. Most of the output of any load testing processes are typically evaluated using a platform that analyzes metrics, he noted.

The k6 platform has been gaining traction among developers that require access to a tool that makes it simpler to dynamically scale load testing up and down as required versus having to guess how much infrastructure might be required to test an application workload, said Dutt. That capability not only makes it simpler to integrate testing within a DevOps workflow, Dutt added, but also serves to reduce testing costs.

In general, Dutt noted testing is shifting further left as developers assume more responsibility for quality assurance. The challenge is finding a way to enable developers to automatically incorporate testing within a continuous integration (CI) process that allows them to easily observe how synthetic tests are executing, added Dutt.

There’s no doubt developers are running more tests before promoting workloads into a production environment as part of an effort to reduce the number of issues that might be encountered when an application is deployed in a production environment. In many cases, the support calls that arise now go directly to developers who now have a vested interest in reducing the volume of those calls.

The issue that developers are contending with is as they embrace microservices, the dependencies that exist across multiple applications makes it more challenging to successfully deploy those applications. Grafana Labs has been making a case for a cloud platform that makes it simpler to centrally view data collected from instances of Prometheus distributed across multiple application development environments. Prometheus, now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) that oversees the development of Kubernetes, is now being deployed more widely by IT teams to observe legacy monolithic applications alongside emerging microservices-based applications.

It’s not clear the degree to which organizations are also employing dedicated application testers. In many cases, those testers will surface issues that developers overlooked (or simply chose to ignore) in the face of tight application delivery deadlines.

In the longer term, however, it’s also apparent artificial intelligence (AI) will be playing a larger role in application testing. Someone will still need to review those tests, but many more rote tasks will increasingly be automated.

One way or another, the total cost of testing is declining, thanks in part to increased reliance on open source testing tools that, in many cases, developers are simply downloading themselves. Those tools are reducing much of the licensing friction and cost restrictions that developers might otherwise encounter.

In fact, the easier it becomes to test applications, the better overall application quality will become in the months and years ahead. At at time when organizations have never been more dependent on software, that potential improvement to the overall state of application quality can’t arrive soon enough.

June 17, 2021
Using Rust to Build Distributed Applications

Rust is an open source programming language that was initially developed at Mozilla Research and became increasingly popular for building distributed applications. It has been referred to in the Stack Overflow Survey as “the most-loved programming language” by software developers for five consecutive years. Moreover, companies like Amazon and Microsoft have recently revealed that they are using Rust to develop the software components that are responsible for ensuring application safety.

Rust allows the implementation of safe and predictable code by leveraging memory safety and speed. It is the ideal choice to create code without incurring undefined or unpredictable behavior thanks to its features such as consistent runtime behavior and a static type system.

Although Rust can be used for any system programming application, it is mainly implemented to build applications like simulation and game engines, browser components and file and operating systems. Rust syntax is similar to C++, but it addresses issues that C and C++ normally struggle with such as developing code without security vulnerabilities, general memory errors and problems in writing concurrent programs.

The Advantages of Rust in Distributed Programming

Rust tackles the performance and reliability problems of other low-level programming languages by using a careful compiler which examines all the variables used and referenced. As the code is compiled, Rust uses monomorphization by creating exclusive and high-performance code for each type of channel. It prevents programmers from paying performance penalties due to its flexibility. Based on the principle that you don’t pay for what you don’t use, the code written in Rust is enhanced and abstractions are solved at compile time making the program safe and without runtime overhead.

Rust doesn’t have a garbage collector, which allows programmers to build abstractions with predictable performance. In Rust, there is no garbage to collect because the moment something would have become garbage, it gets freed immediately at compile time, making the program much faster. Moreover, Rust uses a borrow checker to check where data is used across the program, and by following a set of rules it establishes where data needs to be dropped or initialized. It provides the same advantages of a garbage collector with the efficiency and predictability of manual management.

Another crucial characteristic of Rust is its asynchronous I/O. In Rust, asynchronous programming is widely implemented and well-integrated. It enables developers to effectively scale on a certain number of cores and exploit the operating system resources. By running several units of code on each application, this feature enhances performance and responsiveness of the operating system.

Rust prevents some of the software engineering problems that could critically damage the application development process. These issues concern concurrency and memory safety which can cause very often denial of service, code vulnerabilities or compromised secrets. Examples of these frictions that are common in other languages such as C or C++ include uninitialized variables, undefined behavior, invalid iterators and unexpected variable modification.

Another great advantage of using Rust is the Rust developer community, an extremely friendly and welcoming community. There are multiple events, chat rooms and forums to participate in that makes it even more pleasant to build distributed applications with Rust.

Thanks to its ability to fix concurrency and memory issues, to compile and run safe and predictable code and provide a fast implementation, Rust is quickly increasing its popularity and establishing itself as the ideal choice for building distributed applications.

June 16, 2021
The Future of Low-Code is Open

The low-code market is seeing meteoric rise across the world, as companies try to keep up with digitization demands and shrinking IT budgets. Even as we witness increasing low-code adoption among professional as well as citizen developers, an intriguing question comes to mind – What lies ahead for low-code, and could it ever become a mainstream approach for modern development teams?

The answer may well be an open source, low-code platform that offers high productivity, while supporting seamless integration with the overall fabric of modern software development practices within an enterprise.

It’s feasible to assume that low-code will evolve to become open low-code, resulting in greater innovation and agility.

To further understand what this means, let’s dive deeper. What are open systems?

According to Wikipedia, open systems are computer systems that provide some combination of interoperability, portability and open software standards.

Over the years, the software industry has seen great benefits from designing, implementing and consuming open systems. TCP/IP protocol standards, UNIX systems, Web browsers, REST APIs – all of these are shining examples of open standards that went on to become highly successful and widely adopted. By remaining open, they enabled higher interoperability, streamlined development and fostered rapid innovation.

Low-code is now at a critical stage in its adoption curve. For the last few years, we have seen citizen developers successfully execute shadow IT with low-code and churn out applications at a breathtaking pace. Today, low-code platforms are hardened for enterprise use, are programmed to understand the scalability and security needs of a complex application and have integration capabilities mature enough to seamlessly fit in with existing tools and technologies. As a result, we are now seeing greater adoption of low-code within the professional development community, covering a diverse set of use cases from simple dashboards to complex applications. The natural next evolution of low-code is that it becomes mainstream within enterprise IT, and is used to build mission-critical applications and systems. So, how does this next phase play out for application development?

The Case For an Open Low-Code Platform

The approaches and techniques of modern software development teams has changed dramatically to meet the demands of modern, software-enabled business. Developer velocity and organizational agility have become key benchmarks for high performing software development teams, as those metrics have a direct correlation with software excellence and superior business performance. According to a research report by McKinsey, teams that belong to the top quartile with regards to developer velocity score have 60% higher total shareholder returns and 20% higher operating margins. Such teams can experiment faster and release code to production without delays.

As application teams continue to embrace low-code for mainstream development, it is vital that low-code platforms support developers so they are encouraged to employ modern application development and delivery best practices. Low-code should introduce minimal disruptions to a developer’s working practices and workflow. Also, it is important that low-code can integrate seamlessly with the fabric of the overall enterprise application architecture. This can happen if a low code-platform is open standards-based and flexible so that the rest of the enterprise application infrastructure can coexist with it.

What Makes a Low-Code Platform Open?

Developer-Centric Features

Developers like control, flexibility and a unified experience. They find comfort in sticking to their preferred languages, tools and application development and delivery workflows. A low-code platform that offers productivity with equal flexibility, with a focus on building robust enterprise architecture, is bound to be the future of application development. Platforms should focus on providing a unified developer experience across concept, design, integration, development and deployment stages of the app life cycle, employing a technology stack that is modern, best-of-breed and cloud-native. It’s equally important to provide a way for developers to easily bring any external innovations into the low-code platform.

Visualization, Customization and Ownership

Many low-code platforms do not generate 100% of an application’s code. Also, most of the code generated by proprietary platforms is also proprietary, and quite often remains hidden and not easily accessible or extensible. A platform that generates open standards-based, real code is a great asset, especially for professional developers building complex applications that require extensive customization and deep integration with enterprise tooling (security, testing, debugging, integration etc.). The code generated should be based on developer-friendly, best-of-breed application stacks and standard design patterns. This way, application teams will have complete familiarity with and understanding of the code. Enabling full export of the code allows teams to own the code created by the platform.

Flexible Application Architecture

The application architecture should be loosely coupled, supporting microservices and micro front ends that can be independently built, deployed and scaled. This way, architecture can support cloud-native application development easily. Also, all other aspects of the application life cycle should allow for plug-and-play capability. This includes, but is not limited to, plugging in custom UI components (widgets, templates), custom security providers, custom back end code, logging frameworks, event driven systems, etc. A plug-and-play model ensures that development teams can integrate custom providers that are fine-tuned for the enterprise.

Modern Development Best Practices

Modern application development practices have evolved to allow teams to experiment faster and release code to production at a never-seen-before pace. Optimizations in performance and scalability have resulted in applications that can support millions of end users. As developers warm up to low-code, the platforms should align with and implement all modern development practices while building applications. The idea is to minimize friction in a developer’s journey towards low-code, so that they continue to leverage the same design principles, application tooling and enterprise integrations as they do in the complex programming world.

Infrastructure-as-Code (IaC)

Developers need a way to continuously deploy software so there is always a version of the application ready for production. Low-code platforms should support an IaC option, so code generated is always deployable seamlessly on the developer’s infrastructure of choice. Platform should integrate to build, test and release systems (version control systems, CI/CD, artifact repos, container image repos, Kubernetes clusters and public or private cloud instances, for example). This way, artifacts built by low-code are continuously integrated and deployed to the enterprise’s operational systems.

Low-code is at an inflection point within enterprises, as it becomes the platform of choice for digital transformation and application modernization. This is the opportunity for low-code platforms to become a key ingredient of an enterprise application architecture. An open low-code approach will allow application development teams to benefit from the underlying best practices prevalent within the organization.

Low-code is not merely a productivity tool; it has the potential to be a technological and cultural catalyst that drives enterprise innovation and business agility.

May 20, 2021
Nobl9 Makes SLO Specification Open Source

During an online SLOconf event today, Nobl9 revealed that the platform it created to enable IT teams to achieve service level objectives (SLOs) is now available under an open source Apache license.

Brian Singer, chief product officer for Nobl9, said the goal is to make a YAML specification format for defining SLOs that includes a parser and basic validation and testing capabilities more accessible via an OpenSLO project. Achieving that goal is critical at a time when organizations are deploying microservices-based applications that have dependencies that often adversely impact performance and availability.

While the concept of an SLO and/or a service level agreement (SLA) has been around for a long time, IT teams that have embraced DevOps best practices by hiring site reliability engineers (SREs) are programmatically attempting to assure that SLOs are attained and, just as importantly, maintained, said Singer. Most SLAs have, historically, not been well-enforced. OpenSLO makes it possible to achieve that goal by embedding SLO objectives within a YAML file that become part of a Git-based workflow, he noted.

Niall Richard Murphy, author of the book, Site Reliability Engineering, has signed on to be a core OpenSLO contributor working alongside committers from GitLab, Dynatrace and Nobl9. The ultimate goal is to make it simpler to share and migrate portable SLO specifications across multiple application development projects by constructing them using an object model, said Singer.

Nobl9, meanwhile, will continue to operate a software-as-a-service (SaaS) platform for managing SLOs based on OpenSLO. Singer noted there will be an increased need for OpenSLO as it becomes more widely employed. The Nobl9 SLO platform is compatible with monitoring platforms such as Datadog, New Relic and Prometheus, and uses data collected from monitoring and observability platforms to calculate acceptable rates of error per service. It can be configured to trigger alerts and even workflows in anticipation of outages.

Accessible via a CLI/GUI/API, the platform also enables DevOps teams to create business rules and define “facets” of users based on the application experiences required. DevOps teams can identify users who are being serviced poorly in addition to tracking groups of users. They also can associate contractual obligations to an SLO for a critical business period.

The platform also makes it easier to determine how to make systems more reliable or lower reliability goals to reduce costs when possible. IT organizations will also spend much less time determining the root cause of any issue using a combination of real-time and historical data that is more accessible. Today, it’s not uncommon for IT teams to spend weeks looking for the source of an application degradation issue, only to discover the problem can be fixed in a matter of minutes.

It’s still early days as far as adoption of SLO-as-code is concerned, but the days when SLAs or SLOs were, at best, aspirational statements of intent are coming to an end. The expectation is SLOs will soon be maintained via YAML files embedded within application code and distributed across a rapidly expanding enterprise with more interdependencies than any IT team can manually track.

May 18, 2021
Trend Micro Allies With Snyk to Advance DevSecOps

Trend Micro and Snyk unveiled today a software-as-a-service (SaaS) platform the two companies have jointly developed to identify vulnerabilities in open source code.

The Trend Micro Cloud One – Open Source Security by Snyk platform enables DevOps teams to both identify vulnerabilities and licensing issues to better monitor, prioritize and share information about risk and exposure rates within application development projects.

Trend Micro COO Kevin Simzer said the SaaS platform provides a unified approach that combines six services within a single subscription to enable organizations to better protect a software supply chain.

Snyk CTO Geva Solomonovich said that while the relationship between the two companies is not exclusive an alliance with Trend Micro will enable organizations to employ Snyk tools and the open source vulnerability database to implement a set of best DevSecOps practices within their organization.

Simzer said Trend Micro is also including automation tools that make it easier for cybersecurity teams, along with the rest of the IT organization, to discover what application development projects are underway with their organization. The goal is to provide cybersecurity teams and DevOps teams with a set of tools that provides them with a common language through which they can collaboratively address vulnerabilities.

Trend Micro claims approximately eight hours can be saved per vulnerability through automation and early discovery of the versions of open source code being employed. Roughly 80% of all application code in use today is derived from open source software, noted Trend Micro. That translates to saving more than 650 hours of development time per application, according to the company.

Snyk, meanwhile, claimed to have observed a 2.5x increase in the number of open source vulnerabilities it has discovered over the past three years. In the wake of some recent high-profile breaches the security of software supply chains has become a greater area of focus, with many organizations now implementing a more rigorous review of all the code they employ and any associated dependencies.

It’s still early days as far as adoption of DevSecOps best practices are concerned within most organizations. Responsibility for application security is clearly shifting further left toward developers. As part of that effort, cybersecurity teams are trying to adjust their processes in a way that enables them to vet the efforts of developers without slowing down the rate at which applications are developed. That’s becoming more challenging as the rate at which applications are being developed continues to increase.

The conundrum organizations are trying to navigate is that every minute a developer spends on security is, theoretically, one less minute they have to write applications or business logic. At the same time, however, if vulnerabilities are not addressed early in the development cycle, they may take longer and cost more to fix, especially if they are discovered after an application is deployed in a production environment.

Of course, there may come a day a when application security is just another set of steps to be performed within a quality assurance process. In the meantime, however, a lot more attention is being paid to application security today, in part, to make up for the many sins of the past.

May 10, 2021
Developer’s Guide to Open Source Spring Cleaning
Spring is here, and after a year filled with record-setting digital transformation and its associated vulnerabilities, now is the right time to give the open source components in your codebase a refresh. For many development teams, today’s open source operations present a ‘mess’ that’s difficult to clean up; often, no one knows how many libraries, third-party components or modules are in use, not to mention their vulnerability status. This can create a significant source of risk and technical debt, making a spring cleaning that much more necessary.

The good news is that there are some simple strategies and tools that organizations can implement to jump-start the open source spring cleaning process. Once implemented, these systems will help ensure that your codebase is kept up-to-date and clear of vulnerabilities.

Organizing and Inventorying Open Source

When embarking on your open source clean-up mission, an ideal first step is to take stock of what’s there. Gathering a list of all the relevant libraries and packages in your codebase, along with version information and where in your code they are used, should be your top priority.

Decide to Keep or Toss

There is a strong possibility that some of the components in your library contain vulnerabilities. Be sure to use online databases for a published list of vulnerabilities to easily identify which items may be past their security sell-by date. Consider which ones to update and which to remove altogether if they’re riddled with unpatched flaws.

Polishing, Dusting and Refreshing

Polishing your physical surfaces not only makes them look shiny but also protects them from damage caused by light, water or other natural elements. Digitally polishing your open source security posture should involve keeping your code base defended in a similar manner, which means making repeat security assessments as frequently as possible while also keeping the inventory up-to-date so your teams are always aware of what’s being used.

As a last step in this process, consider dusting off any outdated or existing policy documentation. Give them a spring refresh, as well, so they can account for the changes not only in your open source database but for your entire development team. By ensuring developers are all on the same page regarding policies, responsibilities and best practices, you are effectively setting the stage for the next phase of operational success.

Keeping Your Open Source Code Clean

Sometimes a clean-up becomes more substantial than anticipated and requires some extra muscle. Implementing a dedicated tool to assist with this clean-up will not only make the process faster and easier, but it can also lead to fewer false positives and more accurate results based on your choice of reinforcements.

Software composition analysis (SCA) tools can parse your codebase and discover the libraries, modules or frameworks that are in use, and automatically compare all discovered components against a vulnerability database. Your SCA tool needs two key things to produce actionable results:
- Access to a curated, high-fidelity vulnerability database. Your time is valuable. It’s well worth getting the most accurate data you can, despite what may be marked “vulnerable” or “safe” in the public domain.
- Insight into your code. Just because you are using a vulnerable library does not automatically mean your code is vulnerable. What method in the library is vulnerable – are you even using it in your code? If you are using it, are you passing a static value or some input-derived variable? This is a function described as the ‘Exploitable Path’, and it is critical to focusing your clean-up efforts.
This process will provide a comprehensive list of the flawed modules in use and help you decide what needs to ultimately be kept and what needs immediate attention. With the right tools – and the right data – you can get an accurate, prioritized list of what open source components you should update or depreciate in your code.

While embedding an SCA tool into your development process and workflow alongside your other build and security-focused tools is essential to stop the accumulation of more risk and technical debt, maintaining the quality and freshness of the source vulnerability data is also extremely critical. While retaining an up-to-date list of vulnerable components seems like a full-time job, baking an open source hygiene process into your workflow can be a key component of your database’s overall maintenance.

Evaluating your open source components at build time – and then systematically scheduling reassessment scans to catch newly discovered vulnerabilities in previously ‘safe’ libraries – can bake an open source hygiene process into the developer workflow. This will serve to extend the “spring cleaning” mentality to a year-round endeavor. With the threat landscape continuing to rapidly evolve and vulnerabilities rising by the hour, implementing these simple practices could have a long-lasting impact on your open source infrastructure as it stands today.
May 10, 2021