DEV Community: Kazuma Koga

Are You Still Checking Binary Hardening by Hand? I Built bincheck in Rust

Kazuma Koga — Tue, 21 Apr 2026 13:00:00 +0000

Why I built this

I've worked in embedded development and in security tooling. There was a gap where those two worlds met.

Binary hardening checks — RELRO, PIE, stack protection — are things embedded developers naturally think about. But there's no tool to automate them in CI (at least none I could find). SCA tools check your source code and licenses, but they don't look at the hardening state of the binary you actually ship.

I thought there was demand for something that filled that gap, so I built it.

What are hardening flags?

Hardening flags are security features applied by the compiler or linker at build time. The five main ones for ELF binaries:

RELRO (Relocation Read-Only): Makes the GOT read-only. Full RELRO is ideal.
Stack Canary: A canary value placed on the stack to detect buffer overflows. If it's been tampered with before the function returns, the process terminates.
NX (No eXecute): Marks the stack and heap as non-executable. Basic defense against shellcode injection.
PIE (Position Independent Executable): Required for ASLR (address space layout randomization) to work.
Fortify Source: When built with _FORTIFY_SOURCE, dangerous functions like strcpy are replaced with safer versions that detect buffer overflows at runtime. bincheck detects this by inspecting fortified symbols in the binary.

For PE binaries (Windows EXE/DLL), the equivalent concepts are DEP, CFG, SafeSEH, and ASLR.

Missing any of these doesn't automatically mean a vulnerability, but it lowers the bar for attackers. IoT devices and firmware tend to have long lifespans with infrequent updates — the cost of shipping without hardening is higher than in typical software.

What bincheck does

bincheck is a CLI tool that checks hardening flags in ELF, PE, and Mach-O binaries. Written in Rust, using the goblin crate for binary parsing.

1. SARIF output for GitHub Code Scanning

bincheck firmware.elf --format sarif > results.sarif

Upload the SARIF output to GitHub Code Scanning and you get hardening results in the Security tab. You can track changes per PR.

2. `--strict` as a CI gate

bincheck firmware.elf --strict
echo $?  # returns 1 if any hardening flag is missing

With --strict, bincheck exits with code 1 if any flag is absent. Drop it into your CI pipeline as a gate.

Demo

# Install
cargo install bincheck

# Check an ELF binary (table output)
$ bincheck ./firmware.elf

Binary: ./firmware.elf (ELF, x86_64)
┌─────────────────┬──────────┬───────────────────────────────────────┐
│ Check           │ Status   │ Detail                                │
├─────────────────┼──────────┼───────────────────────────────────────┤
│ RELRO           │ FULL     │                                       │
│ Stack Canary    │ ENABLED  │ found __stack_chk_fail in .symtab     │
│ NX              │ ENABLED  │                                       │
│ PIE             │ ENABLED  │                                       │
│ Fortify Source  │ DISABLED │ no fortified symbols found            │
│ RPATH           │ NONE     │                                       │
│ RUNPATH         │ NONE     │                                       │
└─────────────────┴──────────┴───────────────────────────────────────┘

# JSON output
$ bincheck ./firmware.elf --format json

# SARIF output (for GitHub Code Scanning)
$ bincheck ./firmware.elf --format sarif > results.sarif

# CI gate (exit 1 on missing hardening)
$ bincheck ./firmware.elf --strict && echo "OK" || echo "FAILED"

GitHub Actions

- name: Check binary hardening
  uses: kazu11max17/bincheck@v0.2.0
  with:
    files: ./build/firmware.elf
    strict: true
    format: sarif

- name: Upload SARIF
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: bincheck-results.sarif

Note: the upload-sarif step requires permissions: security-events: write in your workflow.

Closing

bincheck is available here:

crates.io: https://crates.io/crates/bincheck
GitHub: https://github.com/kazu11max17/bincheck

If you're using it on embedded Linux, firmware, or anything cross-compiled — feedback and PRs are welcome.

DevSecOps Without the Pain: The Missing Piece Most Teams Overlook

Kazuma Koga — Thu, 12 Mar 2026 13:00:00 +0000

Introduction: Did Adding “Sec” to DevOps Actually Work?

“Let’s integrate security into DevOps and call it DevSecOps.”

“Let’s shift security left and start checking earlier in development.”

These ideas sound simple in theory. But in reality, what often happens inside organizations looks more like a cold war between development and security teams.

Developers: “Security checks slow down our releases. And half the findings are false positives.”
Security teams: “Developers underestimate risks. Shipping software with vulnerabilities is unacceptable.”

In my career, I’ve supported many organizations transitioning to DevSecOps as a delivery engineer at a global security vendor.

I’ve worked with teams across a wide range of environments—from web services to embedded systems.

One pattern I’ve consistently seen is this:

Teams adopt the tools and build the pipeline structure, but the culture needed to make DevSecOps work never catches up.

In this article, instead of explaining tool configurations, I’d like to share a practical, field-level perspective on what actually makes DevSecOps succeed, based on real-world experience.

1. Dev, Ops, and Sec: Different Goals, Same Pipeline

DevSecOps is supposed to integrate traditionally separate roles.

But in practice, each team often still optimizes for completely different KPIs.

Dev (Development)

Wants to build features, change things, and release quickly.

KPI: Release frequency, lead time
Ops (Operations)

Wants stability and predictability. Ideally nothing breaks at 2 AM.

KPI: Uptime, MTTR
Sec (Security)

Wants to eliminate risk and verify everything before release.

KPI: Vulnerability counts, compliance

Security teams historically acted as gatekeepers, often blocking releases right before deployment.

When security becomes part of the development pipeline, it’s easy for them to be perceived as “the brake pedal.”

If you introduce CI/CD tools while this tension still exists, automation doesn’t solve the conflict—it simply accelerates it.

Successful teams do something different first.

Before tools, they establish a shared language:

Where should we balance speed of delivery and acceptable risk for our product?

Without that agreement, DevSecOps pipelines tend to become battlegrounds rather than collaboration systems.

2. Abandon the “One-Size-Fits-All” DevSecOps Model

Many teams assume there’s a standard DevSecOps template they should follow.

In reality, security priorities depend heavily on the nature of the product.

Web / Cloud-Native Applications

In web services, a large portion of the codebase often comes from open-source dependencies.

Because of this, SCA (Software Composition Analysis) tools are extremely valuable for detecting vulnerabilities in third-party libraries.

Another important factor is that web services can usually be patched and redeployed quickly.

This makes a culture of “detect early and fix fast” more practical than “block everything until it’s perfect.”

SAST tools are still useful for catching issues like XSS or injection vulnerabilities, but many of these problems are also caught through code reviews.

Embedded Systems and IoT (C/C++)

In contrast, the manufacturing environments I’ve worked with operate under very different constraints.

Firmware written in C or C++ is much harder to update after release.

Even when OTA updates exist, they carry significant operational risks.

Just think about automotive recalls.

In these environments, building security into the product before release becomes critical.

Here, priorities often shift toward:

SAST (Static Analysis)
Memory safety
Preventing low-level vulnerabilities early in development

Speed matters less than engineering quality into the product upfront.

Instead of copying the practices of companies like Google or Netflix, teams need to ask:

What level of risk is acceptable for our product?

That said, creating completely custom internal rules can also be dangerous.

A good starting point is usually to adopt vendor or industry best practices first, and then adapt them to your environment.

3. The Missing Piece: The “Translator”

Sometimes organizations already have:

Expensive security tools
Skilled engineers
Automated pipelines

And yet DevSecOps still doesn’t work.

One common reason is the absence of a translator between security and development.

Someone needs to translate:

Security reports filled with technical terminology → into actionable development tasks

And also translate:

Development’s release pressure and deadlines → into realistic security triage and prioritization

This role requires engineers who can move beyond narrow specialization.

When teams operate in silos—

“I’m in security, I don’t know how to fix the code.”
“I’m a developer, security isn’t my responsibility.”

—the DevSecOps pipeline eventually stalls.

In recent years, developers are increasingly expected to understand security principles.

At the same time, security engineers are being asked to understand code and development workflows more deeply.

What modern engineering teams need isn’t just deep specialization.

They also need people willing to step into adjacent domains and help bridge the gaps.

Sometimes the most valuable skill is simply being curious—and a little bit nosy—about problems outside your official role.

4. The Real Meaning of “Shift Left”

“Shift Left” is often misunderstood.

It does not mean pushing security work onto developers.

A better interpretation is this:

Make security issues naturally visible earlier in the development process, when fixing them is still cheap.

For example:

Seeing a potential buffer overflow while writing code in the IDE
Discovering a license issue in a dependency the moment a pull request is opened

If shift-left doesn’t happen, especially in manufacturing environments, the consequences can be severe.

Production schedules are fixed.

Parts have already been procured.

Release dates are announced.

Security evaluation then happens at the last minute.

If vulnerabilities are discovered, there’s often no time left to fix and retest.

In those situations, it’s easy to imagine security being quietly deprioritized.

Developers don’t need to become security experts.

The real goal of DevSecOps is to create an environment where:

Security quality emerges naturally as part of the development workflow.

Closing Thoughts

DevSecOps isn’t something you simply install.

It’s something you cultivate.

Adopting new tools is valuable, but the more important step is having conversations inside your team:

Why is this security check necessary?
Is it creating unnecessary friction for developers?
What level of risk are we willing to accept?

DevSecOps starts not with pipelines, but with shared understanding.