Developer Week CloudX 2023 - Better security and accessibility in the cloud

DevNetwork is a brand you might already recognize, as they put on the DeveloperWeek expo in the spring and API world in the fall. This year, they introduced a new event focused on cloud technology, including accessibility and security, DeveloperWeek CloudX. With a mission to bring together cloud developers, architects, IT & infrastructure professionals, and executives building the cloud ecosystem, the event took place in person from August 15-16, with a chance to participate online from August 22-23. If you missed it, the online portions will be available on demand in the near future.

This first edition of CloudX featured over 100 speakers across multiple stages. Professionals from around the world gathered to share their experiences and best practices about building in the cloud. Here are just a few highlights from the first-ever CloudX.

CloudX Award Winners

This inaugural event also featured the CloudX Awards, a celebration of innovation and excellence, honoring the cloud industry's best companies, products, and services. Check out the winners and see if you are already working with them, or learn if you can take advantage of any of their offerings. Aside from just receiving an award, multiple winners also presented ways to solve cloud scaling issues in a safe and secure way.

This was the case for Skyflow, who won a CloudX award for Cloud Innovation. Attendees were able to attend their Developer Advocate Adam Chan's session "Infra Infiltrated? Yes. PII Exfiltrated? No." where he covered some practical steps that developers can take to mitigate the risk of a data breach, including data minimization, encryption, access control, and secure coding practices.

Cockroach Labs, who won in the category of Cloud Data Platforms, Data Management, or Big Data with their 'cloud first' CockroachDB, also presented a session called "Infrastructure as Code with CockroachDB" by co-presenters Harsh Shah of Cockroach Labs and Jack Chi from Iterable. In this 50-minute session, they laid out how to properly build out IaC in terms of scale and security, with step-by-step code examples showcasing the versatility of both companies' offerings.

GitOps and multicloud complexity

"Multi-cloud is the best of and worst of tech" began Billy Thompson, Solutions Engineering Manager at Akamai as he dove into his session "GitOps: A Strategy for Cloud Durability." He outlined the normal flow companies go through migrating from on-premise servers and networks to the cloud. At first, with perhaps a handful of applications all on a single cloud provider, things stay pretty straightforward. But eventually, almost inevitably, as more and more apps come online, you find yourself living with multiple cloud providers, all with their own requirements, IAM rules, and potential misconfigurations.

Fortunately, there are some standardized ways to approach multicloud: Infrastructure as Code and GitOps. Infrastructure as Code, IaC, lets you define your network, servers, and services in code. Popular options include Terraform from Hashicorp and the Cloud Native Computing Foundation project Crossplane. GitOps, as covered in our article from GitOpsCon, is a way to approach DevOps where your state is declarative, versioned, and immutable. Additionally, any changes to the source code are pulled automatically, and the system itself is continuously reconciled.

The larger your organization, the more likely you will have multi-cloud as an issue. No matter what tools or approach your team chooses, Billy stressed it is vital that teams discuss what multi-cloud really means in terms of configuration requirements and dependency drift.

The hidden dangers of GraphQL

GraphQL is a newer, alternative API query format that has proven to be a faster and more versatile way to fetch and manipulate data than the traditional REST protocol. GraphQL enables "declarative data fetching," where a client can specify exactly what data it needs from an API. While it has become wildly popular in the Jamstack and decoupled CMS space, overall, it is still early for the technology, which only first emerged in 2015. In his session "The DevSecOps Guide to Control and Secure GraphQL APIs," Shahar Binyamin, CEO and co-founder of Inigo, pointed out some potential security pitfalls of this technology and best practices to stay safe.

One of the most significant issues teams adopting GraphQL face is the security ownership question. It is still a newer tech, and internal subject matter experts likely don't exist inside most organizations. It can be hard to know exactly who to turn to about developer, security, or operations issues. This is a common 'maturity pain' that all teams have faced as technology has evolved.

Shahar suggested thinking like an attacker is a great starting point for thinking about security. He said hackers generally follow these three steps:

• Detect - Enumerate over endpoints and find JSON valid and error responses.
• Fingerprint - Based on errors, it is easy to tell what server technology is being used, even the version.
• Exploit - Vulnerabilities in specific GraphQL implementations are well documented, and the knowledgebase is always growing.

Fortunately, Shahar also spelled out some basic steps to eliminate the most common threats.

Protect your queries

Limit the depth and breadth of allowed queries. It is very common for attackers to try to scrape as much data as possible in as little time as possible. Make sure this suspicious activity is accounted for. Allowing for unlimited complexity of requests can also lead to nested circular Denial of Service attacks if a query can be written to be self-referential.

Rate limiting

While most teams will have WAF rules about the number of individual calls made to the API endpoint, it is less common to tune the WAF to look at the number of operations per call. It is possible to launch a complex brute-force attack from a single call. Disallowing calls that contain too many operations per call and keeping watch for multiple calls in a row that are just mutations of the previous call will help the attackers out.

Watch for data scraping.

Just as you should limit what requests come into your API, you should also inspect what data is being returned. A repeated request for a person's name or email is going to be highly unusual behavior. Rate-limiting outbound objects can slow down attackers, giving you time to detect and disallow them.
Those are just a few ways to get started. He also talked about the need for better access controls and how that could be a double-edged sword, slowing down or halting development if done incorrectly but opening the API to the public if not undertaken at all. In addition to his list, you can refer to the OWASP GraphQL Cheat Sheet for more information about securing your GraphQL implementation.

Accessibility means developing for all

In his excellent keynote " Accessibility Testing in Mobile Apps: Including All Users," on day two of CloudX, Marcus Merrell VP of Tech Strategy at Sauce Labs laid out why accessibility matters. On average, 15% of people using your service or product need to use some form of assistive technology. From a business perspective, this means not addressing accessibility can affect the bottom line as users will look for better alternatives. From a compliance standpoint, it means you can be sued if your service ADA rules. Marcus hopes we will all be motivated by morals here and do the right thing for the user because we want everyone to feel included.

According to his research into WCAG standards, 90% of accessibility problems come down to 10 issues. If an organization just works to fix these issues, then it will be on a much better track for being more inclusive.

1. File format conversion issues. If it is jumbled upon transfer to a different format, a screen reader can never parse it. Be sure to test every time a file is converted from `.doc` to `.pdf` or from `.ppt` to `.kth`.
2. Alt text errors. Often, alt text is either too limited to provide any value or way too descriptive past the point of helpfulness. He said we need to accept that many images need to use an empty alt text if they are merely decorative. A picture of a sunflower inside an article about HTTPS tooling might look nice, but if a screen reader suddenly reads a paragraph about that sunflower to someone looking for a technical answer, that is not good.
3. Lack of visual indication of the current focus. Screen reading assistive technology parses any page into logical, semantic chunks (more on this later). If there is no indication of what the screen reader is focused on, it can make it that much harder to cohesively deliver the messaging you want to in the order you intended. He said hitting tab and highlighting parts of a page might seem disruptive, but for the visually impaired, this is magic.
4. Non-descriptive text for hyperlinks. If you are just highlighting "click here" or 'read more…' then you are not giving any context to what that link goes to. Anyone using a screen reader would really appreciate a description of where the link leads. For example, this link takes you to Oregon State University's Descriptive Link guidelines page.
5. Clickable/interactive areas that are too small. If you present a large text box that asks the user to click to agree but only make the radio button 5 pixels high, then you are making it very hard for anyone with dexterity issues to use your side. Instead of making users do "mouse target practice," make the entire text clickable.
6. Improper use of heading elements. While you might think of headers (H1, H2, H3…) as a way to make a page layout look better, assistive technologies rely on them to parse the presented information. Headers should never be used just for style. Fortunately, there are multiple tools that make it easy to test for semantics.
7. Insufficient color contrast. You can easily measure the difference between colors, and some ratios are much more readable than others. This ratio can be easily tested by tools like the WebAIM Constrast Checker, which can help teams working on corporate-approved color palettes ensure they are inclusive to all viewers.
8. Embedding non-accessible elements. It is easy to assume that any third-party code or content we inject into our will be accessible. In reality, it might be bringing down your site's usability overall. Make sure you test after the embedding is complete and not just before.
9. Using the same decorative text for different resources. If you link to your documentation twice on the same page and both references only link to the term 'documentation,' then it will be a challenge for the user to know exactly what to click. While this might feel like a subset of number four, it is enough of an issue Marcus made it its own point.
10. Using overlay products. As he ran out of time, he referred us to this New York Times article about web accessibility overlays. The bottom line is they can open you up to lawsuits while also making your site or product harder to use.

Walking a more secure path

In his session "Context Over Control: Security's New Path," James Wickett, CEO & Co-Founder DryRun Security, walked us through his self-described radical beliefs about security:

• Security is a function of quality.
• Security is a value, not just a cost.
• Developers care about security.
• We need contextual security analysis.

His approach to security focuses on Control, Composition, and Context. He said right up front that context was the most vital. Security as control means enforcing the preset rules and blocking suspicious activities. Security as composition means understanding each component in your environment and the threats they can expose you to. Security as context takes the larger picture into perspective. It asks:

• Who wrote the code?
• What does the app do?
• Are there any critical functions?
• Did the developer pass any security training?

He said all three views on security are important, but only a context-based view considers the experience you are delivering. He compared composition and context as the difference between reading an ingredient list for a recipe and actually eating the taco it produces.

Thinking about the whole organization and the history of the project will lead to better outcomes and improved collaboration, allowing teams to work together more cohesively and with greater agility. Part of the path forward is democratizing security tools and getting the right tools into your developers' hands earlier in the process. We recommend using ggshield as a pre-commit hook for this reason.
James ended his talk by referring us to DryRun Security's Contextual Security Analysis Guide for further insights into this topic.

A safer cloud for all

One of the biggest takeaways from Developer Week CloudX is that everyone is on the same basic journey when it comes to the cloud. No matter where you are on your cloud migration path, at the beginning and just bringing your first apps online, or living the multicloud dream and leveraging IaC consistently, keeping security top-of-mind is critical to success.

At GitGuardian, we believe in taking a more active stance as your cloud security posture, namely setting decoy credentials in place that attackers will trigger when they breach your perimeter or leak your code. This is the whole idea behind GitGuardian Honeytoken. Adding honeytokens in your private environments, beyond just your code, in your productivity apps like Jira and Slack, or your CI environments, can help you cut dwell times down considerably. Attackers will trigger timestamped alarms, giving you their IP, user agent, and attempted action.

There is a lot more to CloudX than we could cover here. Be sure to check out all the amazing talks from Developer Week CloudX when they become available. Let's all make working in the cloud safer, together.