There's a clear need for security in the software systems that we build. The problem for most organizations is that they don't want to spend any money on it. Even if they did, they often have no idea how much to spend. No particular initiative is likely to imbue your system with “security”, but a strong, deep defensive approach is likely to give you a fighting chance of getting it right.
Web Security as applied to APIs in particular are an important part of the plan. In this workshop, we'll show you how approaches to defining “enough” as well as concrete techniques to employ incrementally in your designs.
In this workshop, we will pick a hands on framework for implementation, but the ideas will generally be standards-based and transcend technology choice so you should have a strategy for mapping the ideas into your own systems.
We will cover a broad range of topics including:
There's a clear need for security in the software systems that we build. The problem for most organizations is that they don't want to spend any money on it. Even if they did, they often have no idea how much to spend. No particular initiative is likely to imbue your system with “security”, but a strong, deep defensive approach is likely to give you a fighting chance of getting it right.
Web Security as applied to APIs in particular are an important part of the plan. In this workshop, we'll show you how approaches to defining “enough” as well as concrete techniques to employ incrementally in your designs.
In this workshop, we will pick a hands on framework for implementation, but the ideas will generally be standards-based and transcend technology choice so you should have a strategy for mapping the ideas into your own systems.
We will cover a broad range of topics including:
A client once asked me to take a team that was new to REST, Agile, etc. and put together a high profile, high value commerce-oriented API in the period of six months. In the process of training the team and designing this API, I hit upon the idea of providing rich testing
coverage by mixing the Behavior-Driven Design testing approach with REST.
In this talk, I will walk you through the idea, the process, and the remarkable outcomes we achieved. I will show you how you can benefit as well from this increasingly useful testing strategy. The approach makes it easy to produce tests that are accessible to business analysts and other stakeholders who wouldn't understand the first
thing about more conventional unit tests.
Behavior is expressed using natural language. The consistent API style minimizes the upfront work in defining step definitions. In the end, \you can produce sophisticated coverage, smoke tests, and more that exercise the full functionality of the API. It also produces another organizational artifact that can be used in the future to migrate to
other implementation technologies.
If you ask the typical technologist how to build a secure system, they will include encryption in the solution space. While this is a crucial security feature, in and of itself, it is an insufficient part of the plan. Additionally, there are a hundred ways it could go wrong. How do you know if you're doing it right? How do you know if you're getting the protections you expect?
Encryption isn't a single thing. It is a collection of tools combined together to solve problems of secrecy, authentication, integrity, and more. Sometimes those tools are deprecated because they no longer provide the protections that they once did.Technology changes. Attacks change. Who in your organization is tracking and validating your encryption strategy? How are quantum computing advancements going to change the game?No background will be assumed and not much math will be shown.
If you ask the typical technologist how to build a secure system, they will include encryption in the solution space. While this is a crucial security feature, in and of itself, it is an insufficient part of the plan. Additionally, there are a hundred ways it could go wrong. How do you know if you're doing it right? How do you know if you're getting the protections you expect?
Encryption isn't a single thing. It is a collection of tools combined together to solve problems of secrecy, authentication, integrity, and more. Sometimes those tools are deprecated because they no longer provide the protections that they once did.Technology changes. Attacks change. Who in your organization is tracking and validating your encryption strategy? How are quantum computing advancements going to change the game?No background will be assumed and not much math will be shown.
Security problems empirically fall into two categories: bugs and flaws. Roughly half of the problems we encounter in the wild are bugs and about half are design flaws. A significant number of the bugs can be found through automated testing tools which frees you up to focus on the more pernicious design issues.
In addition to detecting the presence of common bugs, however, we can also imagine automating the application of corrective refactoring. In this talk, I will discuss using OpenRewrite to fix common security issues and keep them from coming back.
In this talk we will focus on:
Using OpenRewrite to automatically identify and fix known security vulnerabilities.
Integrating security scans with OpenRewrite for continuous improvement.
*Free up your time to address larger concerns by addressing the pedestrian but time-consuming security bugs.
One of the nice operational features of the REST architectural style as an approach to API Design is that is allows for separate evolution of the client and server. Depending on the design choices a team makes, however, you may be putting a higher burden on your clients than you intend when you introduce breaking changes.
By taking advantage of the capabilities of OpenRewrite, we can start to manage the process of independent evolution while minimizing the impact. Code migration and refactoring can be used to transition existing clients away from older or deprecated APIs and toward new versions with less effort than trying to do it by hand.
In this talk we will focus on:
Managing API lifecycle changes by automating the migration from deprecated to supported APIs.
Discussing API evolution strategies and when they require assisted refactoring and when they don’t.
*Integrating OpenRewrite into API-first development to ensure client code is always up-to-date with ease.
The typical technologist has a fairly straightforward perspective about the use of resources in modern software systems. They understand the concept of stable identifiers and what some of the HTTP verbs are intended for based upon experiences with the Web.
There is a rich ecosystem of use cases that build upon these basic ideas, however, and in this talk I will demonstrate several of my favorite examples. Drawing upon my pattern-oriented book, I will highlight patterns that surface information, transform it, direct
traffic, and more. These patterns will be presented with intention, consequences, and the usual context we expect in pattern-oriented literature to help us communicate sophisticated design decisions.
Come develop a more sophisticated palette of resource-oriented patterns to help you solve a variety of issues in distributed information systems development.
If you are getting tired of the appearance of new types of databases… too bad. We are increasingly relying on a variety of data storage and retrieval systems for specific purposes. Data does not have a single shape and indexing strategies that work for one are not necessarily good fits for others. So after hierarchical, relational, object, graph, columnoriented, document, temporal, appendonly, and everything else, get ready for Vector Databases to assist in the systematization of machine learning systems.
This will be an overview of the benefits of vectors databases as well as an introduction to the major players.
We will focus on open source versus commercial players, hosted versus local deployments, and the attempts to add vector search capabilities to existing storage systems.
We will cover:
If you are getting tired of the appearance of new types of databases… too bad. We are increasingly relying on a variety of data storage and retrieval systems for specific purposes. Data does not have a single shape and indexing strategies that work for one are not necessarily good fits for others. So after hierarchical, relational, object, graph, columnoriented, document, temporal, appendonly, and everything else, get ready for Vector Databases to assist in the systematization of machine learning systems.
This will be an overview of the benefits of vectors databases as well as an introduction to the major players.
We will focus on open source versus commercial players, hosted versus local deployments, and the attempts to add vector search capabilities to existing storage systems.
We will cover: