Survey: State of Application Architecture Quality

Dustin Byrne — Wed, 27 Jan 2021 22:41:30 +0000

We, at AppLand, are excited to be conducting a market survey for product and software architecture quality.

This 10-minute survey is designed to learn more about both software structural quality and developer efficiency initiatives in software development organizations. “Software structural quality” refers to how well the code meets requirements other than functionality, such as robustness, security, performance and maintainability.

Why should you take it? As with surveys of this type, we will be making the results of this survey public and if we hit our goal of 300+ responses, we will be donating $1,000 to the Girls Who Code organization. By taking a few minutes of your time you will have access to the results and help a good cause.

You can find the survey here:
https://www.surveymonkey.com/r/archsurveygeneral

Uncovering critical data access using AppMaps

Dustin Byrne — Tue, 27 Oct 2020 19:45:03 +0000

As part of a recent hackathon project, I pulled together some data insights from AppMap data.

For those unfamiliar, the AppMap framework is a suite of tools that allows developers to record runtime data from their applications. An AppMap client, essentially an agent, is responsible for capturing this data from a live application. It emits a file containing the recorded execution flow, data snapshots, high level process I/O (think HTTP, SQL queries, etc.) and some application metadata. I figured it would be an interesting experiment to identify different types of data accessed and label their usage.

Here's what I came up with in two days: The AppMap data inspector. The demo link contains some example data so there's no need to come up with your own.

This proof of concept makes some attempt at identifying the following:

Sensitive values such as passwords, auth tokens
Encrypted values such as password hashes
Unencrypted values which should be encrypted
Data persisted within a database
Data provided by a user, such as an HTTP request parameter
Personally identifiable information: SSNs, emails, IP addresses (this may not count as PII, but I left it in for the proof of concept)
Data logged to stdout

A single object can have multiple labels. PII in your application logs? Uh oh! Sensitive data persisting in your database unencrypted? Whoops! References to unencrypted passwords all over the place? Might be a code smell...

I see a ton of potential improvements for this project, but I'm inclined to let it live on as a proof of concept for now.

If you have some ideas of your own, I'd love to hear them in the comments below!

Thanks for reading!

DEV Community: Dustin Byrne

Survey: State of Application Architecture Quality

Uncovering critical data access using AppMaps