DevSecOps Adoption Roadmap: How to Stop Security Vulnerabilities from Early Development with SAST and DAST

A DevSecOps Guide to Blocking Issues from Early Development: Zeroing Out Security Vulnerabilities with SAST and DAST

You've probably heard it on a development team at least once: "Security is something you bolt on later." It's like finishing a building and only then installing a firewall. That "later," however, is exactly where the biggest costs show up. A vulnerability found late in development drives an exponential increase in time, people, and business risk to fix it.

In today's IT environment, speed and stability are everything. Adding security on top often raises the fear that delivery will slow down. Security should no longer be treated as an obstacle that slows you down—it is essential infrastructure that makes sustainable speed possible. This article takes a deep, developer-focused look at practical DevSecOps methods and a tooling roadmap for automating and embedding security across the development lifecycle.

🛡️ Stage 1: Security Habits That Stop Issues at Coding Time (Shift Left Security & SAST)

More than 80% of security vulnerabilities originate in the coding stage. The most effective defense is recognizing and fixing them the moment you write the code. That is the core of Shift Left security.

Fatal Mistakes Developers Commonly Make — and the Defense Code

Here are the two types of mistakes developers make most often.

1. Cross-Site Scripting (XSS) Vulnerabilities These occur when user input is rendered into HTML without validation. An attacker can inject code such as <script>alert('XSS')</script>.

• Vulnerable code (example):
  JavaScript복사

  // 사용자 입력값을 그대로 DOM에 삽입
  document.getElementById('welcome').innerHTML = userInput;

• Defense code (recommended):
  JavaScript복사

  // 텍스트로 취급하여 안전하게 삽입 (HTML 인코딩 필수)
  document.getElementById('welcome').textContent = userInput;

  Key point: Treating user input as plain text rather than HTML tags is the safest approach.

2. SQL Injection (SQLi) Vulnerabilities These occur when user input is concatenated directly into a SQL query string. An attacker can inject a string such as ' OR '1'='1 to bypass authentication.

• Vulnerable code (example):
  Python복사

  # 사용자 ID를 문자열 포매팅으로 쿼리에 직접 삽입
  cursor.execute(f"SELECT * FROM users WHERE username = '{userInput}'")

• Defense code (recommended):
  Python복사

  # 매개변수화된 쿼리(Prepared Statements) 사용
  cursor.execute("SELECT * FROM users WHERE username = %s", (userInput,))

  Key point: Treat user input as a parameter so the database driver automatically handles escaping.

Applying the Principle of Least Privilege in Code

The most fundamental security principle is the Principle of Least Privilege: grant only the minimum permissions required for the work a system or service performs.

For example, if an API endpoint only needs to look up a user profile and does not require Admin privileges, the service account calling that API should have only read-only (Read-Only) permissions.

// [잘못된 예시] 모든 DB 접근 권한을 가진 서비스 계정 사용
@Service
public class UserService {
    // 이 서비스는 읽기만 해야 하는데, write 권한이 부여되어 있음
    public UserDto getUserProfile(Long userId) { ... }
}

// [올바른 예시] 역할 기반 접근 제어(RBAC)를 통해 최소 권한만 부여
@Service
public class UserService {
    // 이 서비스는 오직 조회(SELECT) 권한만 가진 계정으로만 DB 연결
    public UserDto getUserProfile(Long userId) { ... }
}

🛠️ Stage 2: Automated Verification in Build and Test (DAST & SCA)

Even if you reduce mistakes at coding time, vulnerabilities that arise from complex system architecture or library dependencies still need to be caught in the test stage.

SAST vs. DAST: What to Use and When?

💡 Practical tip: The two are complementary. Catch coding errors with SAST, and use DAST to confirm logical flaws in actual service flows. That combination is ideal.

Why Software Composition Analysis (SCA) Matters

One of the most important security areas today is SCA (Software Composition Analysis). Far more often than in the code we write ourselves, security vulnerabilities hide in open-source packages pulled in through external libraries (npm, Maven, and so on). SCA tools check the versions of every library in use and compare them against known CVE (Common Vulnerabilities and Exposures) lists.

🚀 Stage 3: A Strategy for Building a DevSecOps Pipeline That Automates Security

The ultimate goal is to make security verification not a human "inspection," but something that runs automatically as part of the pipeline.

Integrating Security Scans into CI/CD

Using GitHub Actions as an example, you can configure a workflow that automatically runs SAST and SCA checks every time code is pushed.

name: CI/CD Security Scan

on:
  push:
    branches: [ main ]

jobs:
  build_and_scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      # 1. 의존성 설치 및 SCA 실행 (예: npm audit)
      - name: Check Dependencies
        run: npm audit --audit-level critical
        
      # 2. 정적 분석 도구(SAST) 실행 (예: SonarCloud 연동)
      - name: Run SAST Scan
        run: |
          sonar-scanner \
            -Dsonar.projectKey=my-app \
            -Dsonar.sources=. \
            -Dsonar.host.url=http://localhost:9000
            
      # 3. 단위 테스트 실행 (기능 검증)
      - name: Run Unit Tests
        run: npm test

With this pipeline, security vulnerabilities and style-guide violations are automatically filtered out before code is merged into the main branch.

Summary and Conclusion

Security is not the last stage of the development lifecycle (SDLC); it is a requirement that must be considered from the very first stage.

1. Shift Left: Move security checks to the earliest stages of development (IDE, commit time).
2. Automation: Integrate SAST (static analysis), DAST (dynamic analysis), and SCA (dependency analysis) tools into the CI/CD pipeline so machines catch what humans might miss.
3. Culture: Most important of all is building a culture where the whole development team treats a discovered security vulnerability not as a "bug" but as an "opportunity to improve."

Frequently Asked Questions (FAQ)

Q. What is the typical order for a DevSecOps adoption roadmap? A. A common sequence is: ① Attach SAST (static analysis) to CI for early detection of code vulnerabilities ② Scan open-source dependency CVEs with SCA ③ Block hardcoded credentials with secret scanning ④ Scan container images (Trivy) ⑤ Inspect the running app with DAST ⑥ Expand to IaC scanning (Checkov). Don't put everything in from day one—start with SAST+SCA as a gate.

Q. Won't putting security checks in CI slow down the pipeline? A. Running a full scan on every commit will slow things down. A practical policy is to run a fast, change-focused scan (warnings) on PRs, a full scan (blocking) at night or on merge, and fail the build only for High or higher severity.