SECURITY.APP · SOC

Security Center

취약점A weak point in code or configuration that an attacker can exploit.

펜테스트An authorized simulated attack to confirm what can actually be broken into.

OWASPAn international nonprofit that publishes the standard classification of web security flaws.

SECURITY · BUILD + HARDEN

Security experts read your code, line by line.

When you build fast with AI, the service runs — but often even the people who built it don't know where it's weak. byteforce Security Center finds those weak points before an attacker does, and closes them before they turn into incidents. We don't stop after one look. We check again with every deploy.

We don't work from guesswork. We reproduce exactly where and how a system breaks.

Four teams review this code — not an automated tool.

MANUAL CODE REVIEW

Four white-hat teams read, break in, block, and keep watch.

byteforce Security Center puts four teams of practicing white-hat engineers and security specialists directly on your code. When a tool flags a spot, a person attacks it to confirm.

ACTIVEReadWe read the source line by line — not just the tool output.TEAM-01
ACTIVEBreachWe attack it directly and isolate what's genuinely dangerous.TEAM-02
ACTIVEBlockWe hand you a reproducible PoC and concrete remediation steps.TEAM-03
ACTIVEGuardWe re-check against the same criteria with every deploy.TEAM-04

The four teams draw on three lines of background.

PEDIGREE 01Nexon alumniExperience securing large-scale game services.
PEDIGREE 02DEF CONStage experience at the world's largest hacking conference, in Las Vegas.
PEDIGREE 03Active security firmSpecialists currently working in the security industry.

WHAT WE LOOK FOR · ATTACK SURFACE

The attack surface we actually look at during an assessment.

Vulnerabilities already have a well-established classification system. byteforce checks six categories of attack surface across code and infrastructure. What we look for in each is listed under its published vulnerability classification name. Click a chip to open the explanation for that classification.

This is a list of published vulnerability classifications across six attack-surface categories — injection, cross-site, access control, server-side, secrets & infrastructure, and malicious & persistence. Clicking a classification chip opens a dialog with its definition, attack method, and check items. The forensic probe that sweeps each category in sequence is decorative; the list below carries the same content.

Injection
Cross-Site
Access Control
Server-Side
Secrets & Infra
Malicious & Persistence

Classification and technique names come from public standards such as OWASP Top 10, CWE, and OWASP ASVS. What's listed here defines assessment scope — whether a vulnerability actually exists can only be confirmed by assessment.

~45%of AI-generated code has been reported to contain security flaws.Veracode, 2025

Vibe coding turns an idea straight into working code. It's fast — but security tends to get left at the tool's defaults. API keys stay in the client, permission checks go missing on the server, and dangerous input goes through unvalidated. Because the screen looks like it's working fine, the break often doesn't surface until after launch. And once you find out — because user data leaked or the service went down — operations are already hit.

Automated scans alone don't catch all of this. A scanner can flag what looks suspicious, but only a person attacking it directly can tell you whether it's actually exploitable.

Where vibe-coded services break most often

5 check items

byteforce SEC-01–05 check items (5)
No.	Threat	Details
SEC-01	Hardcoded Secrets	Stripe, OpenAI, or Supabase API keys sitting exposed in the client JS bundle.
SEC-02	Missing RLS	Tables in Supabase or Firebase where Row Level Security was never turned on, so anyone can read anyone else's rows.
SEC-03	Injection	Unvalidated input that lets SQL, OS commands, or XSS execute directly.
SEC-04	Vulnerable Dependencies	Shipping with packages that carry known CVEs, unpatched.
SEC-05	Missing Auth	Endpoints that check for login but never verify permission on the server — any call goes through.

Classification follows published AI-code vulnerability reports (OX Security, Veracode, and others).

app.post("/login", (req, res) => {
const { id, pw } = req.body
const q = "SELECT * FROM users " +
"WHERE id = '" + id + "'"
db.query(q, (rows) => {
const KEY = "sk_live_9f3a2c8b"
log(rows)
res.json(rows)
})
})

What makes a whitehacker different from an auto scanner? See it one scene at a time, on real code.

An automated scanner only flags what looks suspicious. Whether it's actually exploitable is something the four teams above determine by attacking it directly.

The cost of not looking

AsymmetryAn attacker only needs to find one way in. A defender has to close every one. It's an uneven fight from the start.
SilenceEven a system that's already been breached can keep running like nothing's wrong. You won't know it's open until you check.
AccumulationEvery deploy adds new places an attacker could get in. Skip the check, and they keep piling up.
AI-written codeThe faster the code was built with AI, the less room there was to think about security — so the flaws often stay in.

KILL CHAIN INTERDICTION

An attack doesn't happen all at once. It comes in stages.

A breach starts with reconnaissance, moves through intrusion and privilege escalation to establish a foothold, then exfiltrates data. Block it at reconnaissance, and intrusion never gets started — byteforce cuts this chain by privilege escalation at the latest, before an attacker can dig in.

KILL01ReconnaissanceScanning the attack surface for a way in.Classifications for this stage: Exposed .env, Exposed Admin Path, Missing Security Headers, Misconfigured CORS.
KILL02IntrusionCrossing the boundary through unvalidated input.Classifications for this stage: SQLi, XSS, SSRF, Path Traversal, XXE.
KILL03Privilege EscalationClimbing from low privilege to high.Classifications for this stage: Broken Access Control, IDOR, JWT Vulnerabilities, Authz Bypass.
KILL04PersistenceLeaving a way back in to hold the position.Classifications for this stage: Backdoor, Webshell, Rootkit, Insecure Deserialization.
KILL05ExfiltrationTaking the data and getting out.Classifications for this stage: RCE, Hardcoded Secrets, Missing RLS, Supply Chain.

The earlier the chain breaks, the less there is to recover from. That's why we start at reconnaissance and intrusion — exposed secrets, unvalidated input, broken access control.

Stage and classification names follow public security standards — OWASP Top 10, CWE, OWASP ASVS.

In plain termsOur white-hat engineers break in first, in the exact order real attackers would — then hand you the fix.

Going deeper — server-side, session, infrastructure

The faster something is built, the more places there are to attack. Beyond the input validation you can see, we check the spots that don't show themselves — where the server makes requests on your behalf, sessions and tokens, cross-origin policy — in the order an attacker would actually move through them.

SSRF · Server-Side Request ForgeryTricking the server into making a request on the attacker's behalf, to pull internal-network access, cloud metadata, or secrets.
RCE · Remote Code ExecutionWhere an attacker gets their own code running on your server — through deserialization, template injection, or file upload.
Broken Access Control · IDORSwapping the ID in a request to read or change someone else's data — what's known as Broken Access Control.
Session Hijacking · JWT VulnerabilitiesAn authentication bypass that hijacks someone else's logged-in state through session fixation, token forgery, or weak signing.
Misconfigured CORS · Missing Security HeadersA loose cross-origin policy or missing security headers strips away the baseline defenses your browser would otherwise enforce.

Classification names follow public standards — OWASP Top 10, CWE, OWASP ASVS. They only set where to look; whether it's actually exploitable is confirmed by a white-hat hacker.

Plenty of vendors will run a scanner for you.

Few will attack it themselves to confirm.

byteforce uses tools to gather what looks suspicious, then a security engineer attacks that spot directly. We don't stop at the automated scan.

What's different

There are broadly three ways to secure a system: run a scanner yourself (DIY), hire a conventional assessment vendor, or work with a team like byteforce that attacks it directly and checks again with every deploy. Here's how the three compare on the same criteria.

byteforce vs. automated scanner tools (SAST/DAST) vs. conventional security vendors — comparison across 6 criteria
Criteria	byteforce	Automated Scanner ToolsDIY · SAST · DAST	Conventional Security VendorsTraditional assessment
Verification method	A person attacks it directly to confirm	Automated pattern matching only	Mostly checklist review
False positives/negatives	A person filters scanner output to isolate real vulnerabilities	High false-positive rate; misses context-dependent flaws	Misses anything outside the fixed scope
Continuity	Re-checked with every deploy (WATCH subscription)	One-time, whenever you run it	One-time per contract
Re-verification	Re-checks the same item after a fix, no limit on retries	Re-running it doesn't confirm the fix actually worked	Usually an extra charge
Built for vibe-coded stacks	Knows exactly where AI-generated code tends to break	Generic rules, tool-agnostic	Standard web-assessment criteria
Fix support	Provides a reproducible PoC and concrete fix steps, and stays with you until it's resolved	Outputs a list of findings, nothing more	Hands over a report, then the engagement ends

A security engineer verifies it directly, we check again with every deploy, and we stay until it's fixed — all three, in one place.

How we assess

ScopingWe first agree on what to look at, how far, and what access is needed.
Static & Dynamic ScanningWe scan the code and the live service with tooling to surface anything suspicious.
Manual VerificationA person attacks every spot the scanner flagged. We don't stop at the automated pass.
ReportYou get a reproducible PoC and concrete remediation steps for each finding.
Re-verificationAfter you fix it, we attack the same item again to confirm it's actually closed.

Automated scanning surfaces what's suspicious; a security engineer attacks it directly to confirm what's actually exploitable.

Rate Card

Rates scale with depth and cadence.

Choose a one-time assessment, or a subscription that checks again with every deploy.

byteforce security assessment rate card — LITE, FULL, WATCH (3 tiers)
Tier	Description	Cadence	Price
LITE	Rapid vulnerability scan	one-time	₩2.9M
FULL	Deep code & infrastructure audit	one-time	₩6.9M
WATCH	Continuous monitoring & re-checks	monthly	₩990K/mo

Prices shown are exclusive of VAT. Final scope and pricing are confirmed in the proposal and may vary by scale. The WATCH monthly subscription can be cancelled anytime.

WATCH doesn't stop at one look. We check again with every deploy.

Every deployEvery code change gets checked against the same criteria — new vulnerabilities are caught before the next release.
Unlimited re-checksFix it, and we verify the same item again — no limit on retries, and we confirm it's actually closed.
Shorter exposure windowThe most dangerous time is while a vulnerability sits open. Continuous monitoring shrinks that window.

WATCH · Governance Loop

Security isn't a one-time look — it's a process that keeps running.

Code built fast needs re-checking with every deploy. byteforce runs that cycle as three stages — policy, control, audit. We define what to look at and how far, build the check into your deploy process, and keep a record of what we looked at and what we blocked. WATCH turns this cycle into a monthly subscription.

PolicySet the scope and criteria — what to look at, how far.
→
ControlBuild the same check into every deploy.
→
AuditRecord what was checked and what was blocked, then review it.

Attack ClassSQLiSQL Injection·Attack ClassNoSQLiNoSQL Injection·Attack ClassOS-CMDOS Command Injection·Attack ClassXXEXML External Entity·Attack ClassSSRFServer-Side Request Forgery·Attack ClassRCERemote Code Execution·Attack ClassDESERInsecure Deserialization·Attack ClassPATHPath Traversal · LFI/RFI·Attack ClassXSSCross-Site Scripting·Attack ClassCSRFCross-Site Request Forgery·Attack ClassIDORInsecure Direct Object Reference·Attack ClassBACBroken Access Control·Attack ClassAUTHZPrivilege Escalation · Authz Bypass·Attack ClassSESSSession Hijacking · Fixation·Attack ClassSQLiSQL Injection·Attack ClassNoSQLiNoSQL Injection·Attack ClassOS-CMDOS Command Injection·Attack ClassXXEXML External Entity·Attack ClassSSRFServer-Side Request Forgery·Attack ClassRCERemote Code Execution·Attack ClassDESERInsecure Deserialization·Attack ClassPATHPath Traversal · LFI/RFI·Attack ClassXSSCross-Site Scripting·Attack ClassCSRFCross-Site Request Forgery·Attack ClassIDORInsecure Direct Object Reference·Attack ClassBACBroken Access Control·Attack ClassAUTHZPrivilege Escalation · Authz Bypass·Attack ClassSESSSession Hijacking · Fixation·

Check ItemOWASPOWASP Top 10·Check ItemCWECommon Weakness Enumeration·Check ItemASVSOWASP ASVS·Check ItemSECRETHardcoded Secrets · Exposed .env·Check ItemCORSMisconfigured CORS · Missing Headers·Check ItemRLSMissing Row-Level Security·Check ItemSUPPLYSupply Chain · Vulnerable Dependencies (CVE)·Attack StageFUZZFuzzing·Attack StageTHREATThreat Modeling·Attack StagePENTESTPenetration Test·Attack StageREDTEAMRed Team·Attack StageRACERace Condition · TOCTOU·Attack StageWEBSHELLWebshell · Backdoor·Attack StageROOTKITRootkit·Check ItemOWASPOWASP Top 10·Check ItemCWECommon Weakness Enumeration·Check ItemASVSOWASP ASVS·Check ItemSECRETHardcoded Secrets · Exposed .env·Check ItemCORSMisconfigured CORS · Missing Headers·Check ItemRLSMissing Row-Level Security·Check ItemSUPPLYSupply Chain · Vulnerable Dependencies (CVE)·Attack StageFUZZFuzzing·Attack StageTHREATThreat Modeling·Attack StagePENTESTPenetration Test·Attack StageREDTEAMRed Team·Attack StageRACERace Condition · TOCTOU·Attack StageWEBSHELLWebshell · Backdoor·Attack StageROOTKITRootkit·

SELF-AUDIT · Self-Check Record

We check our own site against the same standard.

7 checks · run 2026.08.11 17:53 KST

byteforce.ai.kr self-check record — date, check item, result (7)
Date	Check Item	Result
2026.08.11	AUD-01HTTPS enforced on HTTP requests	Enforced308 → HTTPS
2026.08.11	AUD-02Transport security (HSTS) applied	Appliedmax-age 2 years
2026.08.11	AUD-03Admin console blocks unauthenticated access	Blocked401
2026.08.11	AUD-04Admin API blocks unauthenticated access	Blocked401
2026.08.11	AUD-05Secrets exposed in public responses/assets	0 found10 assets checked
2026.08.11	AUD-06Personal data in public API responses	0 foundhandle lookup
2026.08.11	AUD-07보안 응답 헤더(형식 위장·프레이밍·주소 유출)	적용형식 위장 차단 · 외부 프레이밍 차단 · 주소 유출 절제

Target byteforce.ai.kr · re-run right before every deploy. Checks that can't be machine-verified aren't listed here.

Frequently asked

What people ask first

How is this different from just running a scanner?

Up to the point of gathering suspicious spots with a tool, it's the same. The difference is what happens next. A security engineer attacks every spot the scanner flags, strips out the false positives, and keeps only what's actually exploitable. We don't stop at the automated scan.

Do you review services built with vibe coding?

Security Center is built for exactly that kind of code. We start with where AI-generated code breaks most often — hardcoded secrets, missing RLS, missing auth checks. Just tell us your stack and what's worrying you, in a line or two.

Does one assessment cover me for good?

LITE and FULL are one-time assessments. Your code changes with every deploy, and each change can introduce a new vulnerability. That's why the WATCH monthly subscription re-checks against the same criteria with every deploy, and re-verifies fixed items with no limit on retries.

If you find a vulnerability, do you help fix it?

You get a reproducible PoC and concrete remediation steps — not just a list of findings. After you fix it, we attack the same item again to confirm it's actually closed.

What standard defines what you check?

We use published security standards as our checklist — classifications like OWASP Top 10, CWE, and OWASP ASVS. That covers injection (SQLi, XSS), broken access control (IDOR), server-side request forgery (SSRF), remote code execution (RCE), session and auth bypass, secret exposure, and misconfigured CORS or missing security headers. The standard just tells us where to look — a white-hat hacker attacks it directly to confirm what's actually exploitable.

Who actually reviews the code?

Four teams of practicing white-hat engineers and security specialists. Their backgrounds span three lines — Nexon alumni, DEF CON (the world's largest hacking conference, held in Las Vegas), and specialists currently working in the security industry — and they review code through penetration testing, code review, and threat modeling. Whatever a tool flags, they attack it again themselves, from the attacker's seat.

Where do I start?

We'll start by looking at where your current code is weakest. No contract required to begin — a one-line inquiry is enough, and we'll settle scope and access together during scoping.

We'll send you a security assessment proposal

Tell us what you want assessed and your stack, and we'll reply within a business day with a proposal covering scope and timeline. A security engineer reviews it directly.

Contact

Fills in as you enter your name and company.

Assessment target

Whatever you type on the right goes here as-is.

Likely focus areas

Penetration testingSQLi · SSRF · RCE · IDOR
Code reviewHardcoded secrets · vulnerable dependencies

Enter your stack to preview where we usually look first.

In plain terms: these are the areas we usually open first for this combination. Actual findings go into the proposal after the assessment.

Criteria

OWASP Top 10 · ASVS

Priority

Normal

Anything not surfaced here is still settled together in our reply.

Standards & Sources

Our criteria follow public standards.

We assess code and infrastructure threats against OWASP Top 10, CWE, and OWASP ASVS. Where a service embeds an LLM, the items below also map to OWASP Top 10 for LLM Applications, the classification built specifically for AI applications. Standards are only the starting point — a security engineer confirms, hands-on, whether something is actually exploitable.

Hardcoded SecretsLLM02 Sensitive Information Disclosure
InjectionLLM05 Improper Output Handling
Vulnerable DependenciesLLM03 Supply Chain

Threats that don't involve calling an LLM — missing RLS, missing auth, SSRF, IDOR, session bypass, CORS — are assessed under OWASP Top 10, CWE, and ASVS. We don't force them into the LLM-specific classification.

Sources · Primary references

We'll start by showing you where your current code is weakest.

Request a security assessment

Your stack and what's worrying you — one line is enough.

Prefer to reach out directly? contact@byteforce.ai.kr.