Forem: Buffolander

Dealing With Dependency Vulnerabilities

Buffolander — Sun, 31 Aug 2025 21:31:22 +0000

Security is a fundamental aspect of software engineering, and it’s made up of multiple layers - secure coding practices, infrastructure hardening, data protection, and proactive monitoring - including a critical layer: managing the security of third-party dependencies.

Modern applications rarely exist in isolation; they are built on top of large ecosystems of open-source libraries. Each new dependency introduces both functionality and risk.

Tools like GitHub’s Dependabot can automatically monitor known vulnerabilities and open pull requests to update dependencies, reducing some of the operational burden. However, automated updates are not a silver bullet. More comprehensive scanning tools, such as Apiiro, allow organizations to detect vulnerabilities across the entire dependency graph — while still leaving engineering teams in charge of triaging, prioritizing, and patching vulnerabilities.

This article takes as practical example a React with the Yarn package manager, but the steps we’ll cover are universal practices. Whether you’re working in Node.js, Python, Java, Go, or Rust, the same security posture applies: dependency hygiene, regular updates, and careful resolution of transitive risks.

Tool Discrepancies: Apiiro vs Yarn Audit

Apiiro recently flagged two critical vulnerabilities in a React application owned by my team.

My first intuition, run yarn audit:

$ yarn audit --groups dependencies \
  --level high \
  --frozen-lockfile

Yarn reported over twenty critical and high vulnerabilities. But where does the discrepancy in the results between each tool come from?

Data sources: yarn audit (in Yarn Classic) relies on the npm security advisories database, whereas Apiiro aggregates multiple vulnerability databases and correlates them with application context.
Severity scoring: Apiiro may apply additional risk scoring or filtering rules defined by the InfoSec team, surfacing only the issues deemed most relevant or critical for the business.
Configuration: It’s common for security teams to configure Apiiro to focus on certain severity levels or to suppress vulnerabilities that have compensating controls, whereas package manager audits usually report everything.

In short, the differences don’t mean one tool is “wrong”. They reflect different purposes: Yarn’s audit is a raw report of known CVEs, while Apiiro provides a filtered, risk-based perspective.

An structured process

Vulnerabilities are often flagged deep within nested dependencies, not just at the direct dependency level. To handle them effectively, engineers need to understand their application’s lock file and how dependency resolution works — an area often overlooked by less experienced developers.

From my perspective, the process of patching dependency vulnerabilities can be broken down into three clear steps. After each step, you should re-run your package manager’s audit command (or an external tool like Apiiro) to measure the reduction in vulnerabilities and confirm that you’re making progress.

1. Dependency Hygiene

More often than not, unused dependencies are left dangling in applications. These may come from refactored features, copy-pasted snippets, or forgotten experiments. Regardless of the reason, each dependency added should be interpreted—through an InfoSec lens—as an expansion of the application’s attack surface.

Good hygiene means regularly scanning for unused dependencies and removing them. This is not only a best practice for security but also helps reduce application complexity, speed up builds, and minimize supply chain risks.

2. Updating Dependencies

Once your dependency list is clean, the next step is to update dependencies to their latest non-breaking versions. This is trickier than it sounds because package managers handle installation and updates differently.

YARN CLASSIC (v1)

Manually editing versions in package.json and running yarn install sets the version range for the dependency but does not necessarily update transitive dependencies. The lock file may still point to older, vulnerable versions.
Running yarn upgrade {package-name} updates the dependency to the latest version that satisfies the defined range, and rewrites the lock file accordingly.

YARN 2+ (BERRY)

yarn install behaves similarly to Yarn Classic - it respects the lock file and only resolves new versions if the ranges don’t match.
yarn up {package-name} is the equivalent command for updating.

This difference becomes visible in the lock file. While install preserves existing versions unless ranges demand otherwise, upgrade (or up in Yarn 2+) actively pulls in newer versions and ensures your lock file reflects those updates. Less experienced engineers often miss this nuance, leading to a false sense of security when vulnerabilities persist after a manual update.

3. Resolving Nested Dependencies

Sometimes, even after updating direct dependencies, vulnerabilities remain because they exist as nested dependencies one or many levels deep. In these cases, one solution is to use package resolutions. It instructs Yarn to use a specific resolution (specific package version) instead of anything the resolver would normally pick.

The property resolutions is defined at the root of package.json:

{
  "resolutions": {
    "lodash": "4.17.21"
  }
}

The previous example forces Yarn to use a single version of lodash across the entire dependency graph, regardless of which direct dependency introduced it.

Another approach is being laser focused and scope resolutions to a specific dependency paths:

{
  "resolutions": {
    "react-scripts/**/lodash": "4.17.21"
  }
}

After updating your application's resolutions run yarn install to update the dependency resolutions in your lock file.

Done! At this point your application should have been adequately patched up, unless no patch is yet available for one of the compromised nested dependencies.

Such cases should be communicated to InfoSec, ideally including alternatives to replace the compromised library and the respective engineering effort to refactor the application. It would be on them to weight the vulnerability risk, understand wether the compromised dependency is actively maintained and how often security patches are released, and if a refactor would be indeed required.

Final Thoughts

Dependency management is often treated as a background task — until a vulnerability surfaces and suddenly becomes a production risk. By following a structured approach — hygiene, updates, and resolutions — engineering teams can take control of their software supply chain and meaningfully reduce their exposure.

Automated tools like Dependabot and Apiiro are powerful allies, but ultimately, engineers must understand the nuances of their dependency graph, lock files, and package manager behaviors. With this knowledge, vulnerabilities stop being chaotic surprises and become manageable parts of a continuous security process.

Building Robust Error Handling in FastAPI – and avoiding rookie mistakes

Buffolander — Sat, 30 Aug 2025 16:42:03 +0000

FastAPI is an amazing web framework for building HTTP-based services in Python and very accessible to newcomers. Which to some extent might encourage some to skip the documentation in favour of speed – or at least an illusion of it.

When I first started building with FastAPI, I made my fair share of mistakes when it comes to error handling – stack traces would leak into JSON responses because my service was missing a catch-all handler, or I’d raise FastAPI HTTPExceptions deep inside my service layer, mixing presentation details with business logic. The result was leaky abstractions and inconsistent error payloads.

If you’ve ever found yourself in that same boat, this article is for you. Let’s walk through how to design a clean, maintainable exception-handling strategy in FastAPI — one that separates concerns, keeps your clients happy, and generates friendly and predictable errors.

Why Structured Error Handling Matters

Consistency: clients can rely on a predictable error schema no matter which endpoint they hit.
Maintainability: your service code stays framework-agnostic — ready for reusing in background jobs or CLI tools.
Security: you never accidentally leak internal messages or stack traces to end users.
Observability: every unexpected crash ends up in your logs with full context, making root-cause analysis a breeze.

Understanding Application Layers

Before jumping into implementation and framework-specific details, let's zoom out and look at the typical layers in a backend service. This should help us understand where to raise different types of errors and how they're picked u[ and transformed into HTTP responses.

Presentation Layer

This is where requests are received from and responses are returned to clients. Also referred to as controller layer in FastAPI this is represented by routes and the application object.

This layer is responsible for:

Parsing request parameters (body, query string, path parameters).
Returning HTTP responses.
Catching exceptions and formatting them for clients.

In FastAPI, Pydantic is responsible for handling request parameters validation.

Validation exceptions are handled internally by the framework. Custom exception handlers are expected to be implemented on this layer.

Service or (Business Domain) Layer

This is where your core application logic live. It should be:

Framework-agnostic (no FastAPI imports).
Focused on domain logic, e.g. fetching data, enforcing rules, triggering workflows.

This is where custom exceptions are raised, like ItemNotFoundError. These should be descriptive and carry metadata (status code, error code, message) but never return HTTP responses directly.

Infrastructure Layer

This layer interacts with the outside world, including:

Databases
File systems and blob storage
Queues and notifications
Internal and third-party APIs

Catch and wrap external exceptions into domain-specific ones. For example, if a database query fails because the item doesn’t exist, raise ItemNotFoundError instead of leaking a raw SQL exception.

Pydantic vs. Domain Errors

FastAPI (via Pydantic) already nails request validation – missing fields, wrong types, malformed JSON. All those cases get seamlessly turned into nice 422 Unprocessable Content responses, but there’s a big gap left:

Syntactically valid requests that just can’t be processed in your application domain (due to violation of business rules), lookup failures, rate limits, authentications and authorization checks — these are on you to handle.

That’s where custom exceptions and global handlers come into play.

Crafting Custom Exceptions

Define a lightweight base exception that carries all the info you need:

# exceptions.py

class AppBaseException(Exception):
    def __init__(
        self,
        message: str,
        error_code: str,
        status_code: int = 400,
    ):
        self.message = message
        self.error_code = error_code
        self.status_code = status_code
        super().__init__(message)

Build specific cases on top of AppBaseException:

# exceptions.py

# ...

class ItemNotFoundError(AppBaseException):
    def __init__(
        self,
        item_id: int,
    ):
        super().__init__(
            message=f"Item {item_id} not found",
            error_code="item_not_found",
            status_code=404
        )

class QuotaExceededError(AppBaseException):
    def __init__(self):
        super().__init__(
            message="API quota exceeded",
            error_code="quota_exceeded",
            status_code=429
        )

These exceptions live in your business logic layer. They know nothing about FastAPI’s HTTP mechanisms, which makes them perfectly reusable elsewhere.

Mapping to HTTP Responses with Handlers

Instead of raising HTTPException deeply within your services, prefer catching custom exceptions at the application level:

# exception_handlers.py

import logging, traceback

from fastapi import Request
from fastapi.responses import JSONResponse

from .exceptions import AppBaseException

logger = logging.getLogger(__name__)

def register_exception_handlers(app):
    @app.exception_handler(AppBaseException)
    async def app_exc_handler(
        request: Request,
        exc: AppBaseException,
    ):
        return JSONResponse(
            status_code=exc.status_code,
            content={
                "error": exc.error_code,
                "message": exc.message,
            },
        )

    @app.exception_handler(Exception)
    async def catch_all_handler(request: Request, exc: Exception):
        logger.error(
            "UnhandledException:\n%s", 
            "".join(
                traceback.format_exception(
                    type(exc),
                    exc,
                    exc.__traceback__,
                )
            )
        )
        return JSONResponse(
            status_code=500,
            content={
                "error": "internal_server_error",
                "message": "Something went wrong. Please try again later.",
            },
        )

The first handler cleanly transforms known domain errors into the right status code and JSON shape.
The second one is your catch-all. Any unexpected NameError, ValueError, or database hiccup will still produce a 500 with a generic message and log the full traceback.

Wiring It Up

Here’s how the pieces glue together in a minimal FastAPI app:

# services.py

from .exceptions import ItemNotFoundError, QuotaExceededError

def get_item(item_id: int):
    """This is just a dummy service layer.

    In an actual application it should be importing a DB or
    a third-party API client, for example.
    """
    if item_id == 999:
        raise ItemNotFoundError(item_id)
    if item_id == 777:
        raise QuotaExceededError()
    return {"id": item_id, "name": "Sample Item"}

# routes.py

from fastapi import APIRouter

from .services import get_item

router = APIRouter()

@router.get("/items/{item_id}")
async def read_item(item_id: int):
    return get_item(item_id)

# main.py

from fastapi import FastAPI

from .exception_handlers import register_exception_handlers
from .routes import router  # your APIRouter with endpoints

app = FastAPI()
app.include_router(router, prefix="/api")
register_exception_handlers(app)

Logging & Observability

A global error handler without logging is like a fire alarm you can’t hear. Make sure you:

Use a structured logger (e.g., JSON output) so you can filter by error_code.
Include a request or correlation ID in every log line for tracing – that should be handled in a middleware and is out of the scope of this article.
Ship errors to an observability service like Sentry, Datadog, or AWS CloudWatch where your monitors can trigger alerts in case of anomalies.

Wrapping Up

By keeping your exceptions domain-focused and your handlers HTTP-focused, you’ll end up with:

Cleaner, more testable service code
Consistent error payloads for every endpoint
A safety net that catches the unexpected
Secure APIs that never spill internal details

Start with this skeleton the next time you spin up a FastAPI project. You (and your on-call teammates) will thank yourself when that 2 AM pager alert finally goes silent.

Happy coding! 🚀

The Thin Line Between Psychological Safety and the Comfort Zone

Buffolander — Wed, 16 Apr 2025 09:35:52 +0000

When I began my professional life a long time ago (on the business side, not in software engineering), feedback used to be direct. If you made a mistake, you'd hear about it - often bluntly - and were expected to improve. There was no buffer between performance and critique.

Fast forward to today, and it feels like the pendulum has swung in the opposite direction. Now, criticism is often seen as a threat to psychological safety, and even well-meant feedback can be interpreted as damaging or watered down to such extent it does not generate any improvement.

This shift has raised a difficult but necessary question: have we gone too far in protecting psychological safety at the expense of performance or is it something else we're doing wrong?

TL;DR: This isn't a critique of psychological safety - it's a call to reclaim its actual meaning.

Where did psychological safety come from?

The concept of psychological safety was introduced by Harvard professor Amy Edmondson in 1999. Her research on hospital teams revealed that those who reported more mistakes weren't underperforming - they were simply more transparent. They felt safe enough to speak up, admit failure, and collaborate without fear.

The idea gained widespread traction in 2015 through Google's Project Aristotle, which found that psychological safety was the top trait of high-performing teams. This kicked off a wave of company culture initiatives focused on creating safer, more inclusive environments.

Since then, psychological safety has become a buzzword in every modern workplace. From HR workshops to engineering offsites, we've been taught that creating a "safe space" is the path to innovation, collaboration, and long-term performance. And to a degree, this is absolutely true.

But there's a catch - psychological safety doesn't mean the absence of discomfort. It doesn't mean avoiding criticism. And it certainly doesn't mean lowering the bar.

The danger of misinterpretation

The problem isn't with psychological safety itself - it's with how it's often misunderstood and misapplied. When teams adopt the language of safety without balancing it with clear standards, accountability, and candid feedback, the result is what Amy Edmondson calls the Comfort Zone.

Let's break down her learning zone model, which illustrates this dynamic:

              Standards.High          Standards.Low
Safety.High   Learning zone (ideal)   Comfort zone (complacency) 
Safety.Low    Anxiety zone (fear)     Apathy zone (disinterest)

In the Learning Zone, people feel safe to speak up and are held to a high bar. Mistakes are seen as opportunities to improve, but not as acceptable outcomes in themselves. It's a productive tension - people are both supported and challenged.

But many teams today fall into the Comfort Zone, where psychological safety is mistaken for emotional comfort, and where giving direct feedback is seen as a threat to morale. Here, the language of empathy becomes a shield for mediocrity. Difficult conversations are avoided. Underperformance lingers. High performers get frustrated.

What the research actually says

Several studies have reinforced the value of psychological safety - but always in the context of clear expectations and performance standards.

Amy Edmondson, in her book The Fearless Organization, emphasizes that psychological safety is not about being nice or lowering the bar. It's about creating a space where people can speak up - and then be expected to deliver.
Google's Project Aristotle identified psychological safety as critical, but it was only one of several key traits. Others included dependability, structure and clarity, and impact of work. In other words, safety mattered - but so did discipline.
A report from McKinsey in 2021 found that teams with both high psychological safety and clear accountability outperformed all others. Teams with only one of the two (e.g., high safety but low standards) showed mixed or even negative results.
In Charles Duhigg's book, Smarter Faster Better, high-performing teams are described as having both trust and tension. They allow disagreement, but tie it back to action. They value reflection, but also execution.

These studies consistently show that psychological safety is a performance enabler - but only when paired with strong leadership, clarity, and accountability.

What it looks like when it goes wrong

The consequences of getting this balance wrong are visible in many modern teams. In environments where psychological safety is emphasised without enforcing high standards, teams may appear harmonious on the surface - but underneath they're stalling. The gap between psychological safety and performance isn't just theoretical - it shows up in team dynamics every day.

In many modern engineering teams, especially those that prioritise flat hierarchies and consensus-driven cultures, the line between support and accountability can get blurry. Conversations meant to drive clarity are postponed to "protect morale."

Critical feedback is softened or skipped entirely in the name of being "supportive." The intention is good, but the result is often a team that's emotionally safe and operationally stagnant.

In Agile squads, this can show up as endless retrospectives with little follow-through, or sprint planning sessions where no one challenges vague or unrealistic tickets. Code reviews drift into rubber-stamping. Performance issues linger without being addressed directly, and over time, mediocrity becomes normalised.

Meanwhile, high performers begin to disengage. They want feedback, clarity, and challenge - but when those things are missing, motivation fades. Worse, when everyone is treated the same regardless of their output or the quality of their work, it sends a clear message: performance doesn't really matter here.

All of this contributes to a culture where psychological safety turns into emotional insulation. Difficult conversations are seen as threats rather than opportunities. The team may feel cohesive, but not driven. Safe, but not ambitious.

In that comfort zone, teams stop growing.

This isn't psychological safety - it's quiet decline, disguised as empathy.

Reclaiming the balance: Safety + Standards

So how do we walk the tightrope? How can leaders, engineering managers, and ICs foster psychological safety without lowering the bar?

Redefine Psychological Safety
Remind your team that psychological safety means being safe to speak up, not safe from feedback. You don't build safety by avoiding conflict - you build it by handling conflict well.
Set Explicit Standards
Be clear about what "good" looks like - code quality, project management, architecture design, delivery timelines, ownership expectations, etc. When standards are vague, people default to their comfort zone, they never seek fixing their skill gaps.
Make Feedback Normal, Not Exceptional
Create a rhythm for feedback - weekly one-on-ones, retro rituals, code reviews. Feedback shouldn't be an event; it should be a habit.
Coach Through Discomfort
When people struggle, don't rush to protect them from the pain of failure. Instead, walk with them through it. Growth often starts where comfort ends.
Hold the Line
Don't let poor performance slide under the guise of empathy. Respect people enough to tell them the truth about how they're doing - and trust them enough to believe they can improve.

A false binary

One of the biggest challenges today is the false binary between kindness and rigour, empathy and accountability. Leaders are often made to feel that they must choose: protect people's emotions or raise the bar.

But great leadership doesn't live at either extreme. It lives in the ability to care deeply and challenge directly.

It's telling someone they missed the mark - and still believing in them. It's holding someone accountable while investing in their growth. That's how trust is built - not through avoidance, but through honesty.

We're living in a workplace culture that values empathy - and that's a good thing. But empathy without standards leads to pity, not progress. And safety without accountability breeds comfort, not competence.

The real goal isn't to avoid discomfort - it's to create an environment where discomfort leads to growth. That's the Learning Zone. That's where high-trust, high-performance teams live.

So let's stop seeing psychological safety as the absence of criticism, and start seeing it as the presence of trust, honesty, and shared ambition. Because the teams that grow the most aren't the ones that feel safe all the time - they're the ones that feel safe enough to be challenged.

That's the thin line, and learning to walk it well certainly is an important leadership skill to be developed.