Notices by Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange), page 2

If I'd been forced to write separate login invitations manually for each segment of the user population, I would also have been forced to do more fine grained testing and take more care to ensure it works and think through the details.

But as a starryeyed new engineer, I was too excited by the idea of automating the whole thing in one go. I made it too easy to distribute the impact of my mistake, and I wasted the time of thousands of users.

Early in my career, I built a system for a customer that made it easier for their university to automate sending invitations and login instructions for new users.

I missed some key differences in some user environments that weren't covered in my testing, and I ended up sending thousands of malformed login invitations... twice.

1. Those tools are maintained by security software engineers many years after the original authors left the company

So it's rather important that those tools are easy to understand and maintain. Readable code, composable parts, unit and integration tests, etc.

5. Within security (with insecurity?), we always consider how the ever-evolving threat landscape may affect these systems.

With all the complexity being discussed here, security can seem intimidating—but through tools (and abstractions) like threat modeling, we can focus on the most likely goals of threat actors, what we most want to protect or prevent (e.g., confidentiality/integrity/availability), and the steps of an attack chain where we can most effectively prevent or detect.

4. Infrastructure platforms are intricately collaborative sociotechnical systems of systems, with interactive intertwined layers of domains, teams, and expertise across networking, security, hardware/cloud, developer-facing interfaces, and the many abstractions of/by/for each of these.

So all of the above and below aspects of software happen within these collaborative sociotechnical systems. We design, implement, maintain, operate, retire, and so on, all through collaboration to think about and plan in advance around things like downstream dependencies if something were to go wrong or if we consider retirement, or how we're affected by upstream decisions/incidents/etc.

3. We think about when to RETIRE software! We probably haven't retired enough.

Merge the useful parts into newer systems (or rewrite then if that makes sense). Hand off tools or systems that are no longer part of a team's scope, maybe to more relevant teams or to the downstream teams that depend on it, or to upstream teams who are a better fit for owning that product, etc.

Whatever the direction should be, retirement of software is a topic to think about intentionally and regularly.

2. On the order of 60 tools were historically maintained by about 8 people for most of the last 10 years.

Granted, half of those tools are glorified scripts, tiny little things. But it was manageable to operate and maintain 60 tools by 8 people because they were built for reliability and resilience, within a resilient platform that made it easy to operate software, redeploy instances and entire clusters, etc.

And it continues to be reasonable to maintain and operate because the code is written with clear logging, errors, monitoring, etc. (Okay, most of it. There are gaps, so this also involved a lot of luck 😅.)

So it's important to be thoughtful from the design stage and regularly in maintaining it about how software will be operated and maintained — and retired! — in the long-term over the years.

OpenTelemetry and generally distributed tracing techniques have been transformative for software engineering in exactly the way that GenAI has not been.

I'm a mathematician, and I've loved machine learning since I first learned about Markov chains. Some of my earliest code was machine learning…back in the 1990s when we called it mathematical modeling.

In my opinion, one of the most transformative advances in machine learning is having cloud-based tools that make it easier to develop and iterate on models, handle data, etc. That and tools like TensorFlow nearly democratized development of relatively good ML capabilities like recommendation systems or automated labeling.

Writing software involves considerations across many areas (including and beyond design, maintenance, operations, and security), all within collaborative sociotechnical systems.

Writing software has evolved SO much since my mother was punching stacks of cards in Assembly! We have higher level languages and compilers that optimize code, memory safe languages, cloud computing, Infrastructure-as-Code, etc.

A good example of how software engineering has evolved: One of the hardest problems 15 years ago was "which part of this complex distributed system is broken?" And although tracing methods go back to basic print debugging (in the 1960s if not earlier), open source products like OpenTelemetry is what turned this virtually overnight into a solved problem.

One of the problems with vibe coding is that the hardest part of software engineering is not writing the code, rather it's *choosing* what to code, and designing the system (and, later on, maintaining the code/operations/etc)

The barriers and investment cost to writing code is itself a *desirable* aspect of software engineering because it forces you to make careful, good choices before you invest in building something

Because the majority of the time spent writing, say, curl, is not writing the original tool but rather maintaining it over time, it's important to make good choices from the beginning, and at every major version change

@dalias @soatok
Yeah, request isn't the right word, but couldn't think of something that covers the various Actions governments do to get data they want

@soatok
👀 are government data requests a form of endpoint attack?

@skinnylatte my wife and I have been thinking for a while about moving to Zurich (she's lived and worked from Zurich in the past)

And when you mentioned social isolation, my first thought was "but we have social isolation at home" 💀💀💀

I would like to walk into a forest, curl up under a tree, and become part of the mossy forest floor forever

Coming up with the world's worst "Would you rather" questions to ask your team

"Would you rather have psychological safety forever but only with one person, or psychological safety only one time with each person?"

"Would you rather do one 360-degree feedback or 360 one-degree feedbacks?"

[updating page to degree as @irvingreid suggested]

"Would you rather fight one bear-sized Keeper Test, or 100 Keeper-Test-sized bears?"

"Would you rather run into a bear or the Keeper Test alone in the woods?"

"Would you rather interview one developer or develop one interviewer?"