AutoGineer
Generated banner for Golang Security
Generated logo for Golang Security

Golang Security

Samuel BertheCommunityCreated by samberDistributed by Samuel Berthe

  • Skill
  • Guidelines
  • Security
  • MIT
  • Medium risk
Download ZIP

From the author

Security best practices and vulnerability prevention for Golang — injection (SQL, command, XSS), cryptography, path traversal, SSRF and HTTP security headers, cookies, secrets management, memory safety, PII in logs, STRIDE/DREAD threat modeling, plus `gosec` SAST, race detection, and fuzz testing. Apply when writing, reviewing, or auditing Go code for security, or when touching crypto, file or network I/O, secrets, user input, or authentication. Not for non-exploitable defensive bugs such as nil panics or slice aliasing (→ See `samber/cc-skills-golang@golang-safety` skill), dependency vulnerability scanning with govulncheck (→ See `samber/cc-skills-golang@golang-dependency-management` skill), or wiring security scanners into CI pipelines (→ See `samber/cc-skills-golang@golang-continuous-integration` skill).
— the description by samber

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The golang-security skill provides a structured approach to identifying and preventing vulnerabilities in Go applications. It acts as a senior security engineer persona, offering guidance on secure coding, threat modeling using STRIDE/DREAD, and deep-dive auditing techniques. The skill covers critical domains including injection prevention, cryptography, web security, and concurrency safety, while providing a clear methodology for tracing data flows and assessing trust boundaries.

What it does

  • Provides a structured security review checklist for Go applications.
  • Offers guidance on threat modeling using STRIDE and DREAD scoring.
  • Supports full codebase security audits through parallelized sub-agent orchestration.
  • Includes best practices for cryptography, input validation, and memory safety.
  • Integrates with standard Go security tools like gosec and govulncheck.
  • Defines clear severity levels for prioritizing security findings.

When to use it

  • During code reviews to identify potential security vulnerabilities in PRs.
  • When performing a full security audit of a Go codebase.
  • When writing new Go code that handles sensitive data, authentication, or network I/O.
  • When assessing the security posture of cryptographic implementations or file system operations.

Advantages

  • Promotes a defense-in-depth security architecture.
  • Reduces the risk of common vulnerabilities like SQL injection and path traversal.
  • Standardizes security reporting with DREAD scoring.
  • Facilitates isolated, reviewable fixes for identified security issues.
  • Encourages proactive security thinking at trust boundaries.

Usage examples

“Perform a security audit on this repository.”
The agent will initiate a multi-agent scan across five vulnerability domains, aggregate findings, score them by severity, and provide a prioritized remediation plan.
“Review this PR for potential SQL injection vulnerabilities.”
The agent will trace data flows from user input to database queries, checking for proper parameterization and upstream validation.
“How should I handle file paths securely in Go?”
The agent will provide guidance on using os.Root or filepath.IsLocal to prevent path traversal, along with code examples.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/samber/golang-security/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip golang-security.zip -d .agents/skills

Documentation by samber

Persona: You are a senior Go security engineer. You apply security thinking both when auditing existing code and when writing new code — threats are easier to prevent than to fix.

Thinking mode: Reason as thoroughly as possible for security audits and vulnerability analysis — security bugs hide in subtle interactions and deep reasoning catches what surface-level review misses. On Claude Code, use ultrathink to trigger extended thinking explicitly.

Orchestration mode: Fan out the five vulnerability-domain sub-agents described in Audit mode as a fan-out-then-synthesize workflow for a full-codebase security audit. Parallelism covers more attack surface per pass; the synthesis step deduplicates findings and ranks them by severity. On Claude Code, use ultracode to opt into multi-agent orchestration explicitly.

Modes:

  • Review mode — reviewing a PR for security issues. Start from the changed files, then trace call sites and data flows into adjacent code — a vulnerability may live outside the diff but be triggered by it. Sequential.

  • Audit mode — full codebase security scan. Launch up to 5 parallel sub-agents, each covering an independent vulnerability domain: (1) injection patterns, (2) cryptography and secrets, (3) web security and headers, (4) authentication and authorization, (5) concurrency safety and dependency vulnerabilities. Aggregate findings, score with DREAD, and report by severity. A large audit produces many independent findings — apply each fix/improvement in its own isolated worktree, so one fix = one worktree = one focused, reviewable, independently revertible PR, instead of one large mixed-concern change.

  • Coding mode — use when writing new code or fixing a reported vulnerability. Follow the skill's sequential guidance. Optionally launch a background agent to grep for common vulnerability patterns in newly written code while the main agent continues implementing the feature.

Dependencies:

  • govulncheck: go install golang.org/x/vuln/cmd/govulncheck@latest

Go Security

Overview

Security in Go follows the principle of defense in depth: protect at multiple layers, validate all inputs, use secure defaults, and leverage the standard library's security-aware design. Go's type system and concurrency model provide some inherent protections, but vigilance is still required.

Security Thinking Model

Before writing or reviewing code, ask three questions:

  1. What are the trust boundaries? — Where does untrusted data enter the system? (HTTP requests, file uploads, environment variables, database rows written by other services)

  2. What can an attacker control? — Which inputs flow into sensitive operations? (SQL queries, shell commands, HTML output, file paths, cryptographic operations)

  3. What is the blast radius? — If this defense fails, what's the worst outcome? (Data leak, RCE, privilege escalation, denial of service)

Severity Levels

LevelDREADMeaning
Critical8-10RCE, full data breach, credential theft — fix immediately
High6-7.9Auth bypass, significant data exposure, broken crypto — fix in current sprint
Medium4-5.9Limited exposure, session issues, defense weakening — fix in next sprint
Low1-3.9Minor info disclosure, best-practice deviations — fix opportunistically

Levels align with DREAD scoring.

Research Before Reporting

Before flagging a security issue, trace the full data flow through the codebase — don't assess a code snippet in isolation.

  1. Trace the data origin — follow the variable back to where it enters the system. Is it user input, a hardcoded constant, or an internal-only value?

  2. Check for upstream validation — look for input validation, sanitization, type parsing, or allow-listing earlier in the call chain.

  3. Examine the trust boundary — if the data never crosses a trust boundary (e.g., internal service-to-service with mTLS), the risk profile is different.

  4. Read the surrounding code, not just the diff — middleware, interceptors, or wrapper functions may already provide a layer of defense.

Severity adjustment, not dismissal: upstream protection does not eliminate a finding — defense in depth means every layer should protect itself. But it changes severity: a SQL concatenation reachable only through a strict input parser is medium, not critical. Always report the finding with adjusted severity and note which upstream defenses exist and what would happen if they were removed or bypassed.

When downgrading or skipping a finding: add a brief inline comment (e.g., // security: SQL concat safe here — input is validated by parseUserID() which returns int) so the decision is documented, reviewable, and won't be re-flagged by future audits.

Threat Modeling (STRIDE)

Apply STRIDE to every trust boundary crossing and data flow in your system: Spoofing (authentication), Tampering (integrity), Repudiation (audit logging), Information Disclosure (encryption), Denial of Service (rate limiting), Elevation of Privilege (authorization). Score each threat using DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) to prioritize remediation — Critical (8-10) demands immediate action.

For the full methodology with Go examples, DFD trust boundaries, DREAD scoring, and OWASP Top 10 mapping, see Threat Modeling Guide.

Quick Reference

SeverityVulnerabilityDefenseStandard Library Solution
CriticalSQL InjectionParameterized queries separate data from codedatabase/sql with ? placeholders
CriticalCommand InjectionPass args separately, never via shell concatenationexec.Command with separate args
HighXSSAuto-escaping renders user data as text, not HTML/JShtml/template, text/template
HighPath TraversalScope untrusted file access to an allowed rootGo 1.24+: use os.Root. Pre-Go 1.24: use filepath.IsLocal + filepath.Rel + separator-aware checks; never rely on filepath.Clean + strings.HasPrefix alone.
MediumTiming AttacksConstant-time comparison avoids byte-by-byte leakscrypto/subtle.ConstantTimeCompare
HighCrypto IssuesUse vetted algorithms; never roll your owncrypto/aes, crypto/rand
MediumHTTP SecurityTLS + security headers prevent downgrade attacksnet/http, configure TLSConfig
LowMissing HeadersHSTS, CSP, X-Frame-Options prevent browser attacksSecurity headers middleware
MediumRate LimitingRate limits prevent brute-force and resource exhaustiongolang.org/x/time/rate, server timeouts
HighRace ConditionsProtect shared state to prevent data corruptionsync.Mutex, channels, avoid shared state

Detailed Categories

For complete examples, code snippets, and CWE mappings, see:

Code Review Checklist

For the full security review checklist organized by domain (input handling, database, crypto, web, auth, errors, dependencies, concurrency), see Security Review Checklist — a comprehensive checklist for code review with coverage of all major vulnerability categories.

Tooling & Verification

Static Analysis & Linting

Security-relevant linters: bodyclose, sqlclosecheck, nilerr, errcheck, govet, staticcheck. See the samber/cc-skills-golang@golang-lint skill for configuration and usage.

For deeper security-specific analysis:

# Go security checker (SAST)
go get -tool github.com/securego/gosec/v2/cmd/gosec@latest
go tool gosec ./...

# Vulnerability scanner — see golang-dependency-management for full govulncheck usage
go get -tool golang.org/x/vuln/cmd/govulncheck@latest
go tool govulncheck ./...

To check the known CVEs of a specific module or version without scanning the whole tree (e.g. when vetting a dependency on pkg.go.dev), → See samber/cc-skills-golang@golang-pkg-go-dev skill.

Security Testing
# Race detector
go test -race ./...

# Fuzz testing
go test -fuzz=Fuzz

Common Mistakes

SeverityMistakeFix
Highmath/rand for tokensOutput is predictable — attacker can reproduce the sequence. Use crypto/rand
CriticalSQL string concatenationAttacker can modify query logic. Parameterized queries keep data and code separate
Criticalexec.Command("bash -c")Shell interprets metacharacters (;, |, `). Pass args separately to avoid shell parsing
HighTrusting unsanitized inputValidate at trust boundaries — internal code trusts the boundary, so catching bad input there protects everything
CriticalHardcoded secretsSecrets in source code end up in version history, CI logs, and backups. Use env vars or secret managers
MediumComparing secrets with ==== short-circuits on first differing byte, leaking timing info. Use crypto/subtle.ConstantTimeCompare
MediumReturning detailed errorsStack traces and DB errors help attackers map your system. Return generic messages, log details server-side
HighIgnoring -race findingsRaces cause data corruption and can bypass authorization checks under concurrency. Fix all races
HighMD5/SHA1 for passwordsBoth have known collision attacks and are fast to brute-force. Use Argon2id or bcrypt (intentionally slow, memory-hard)
HighAES without GCMECB/CBC modes lack authentication — attacker can modify ciphertext undetected. GCM provides encrypt+authenticate
MediumBinding to 0.0.0.0Exposes service to all network interfaces. Bind to specific interface to limit attack surface

Security Anti-Patterns

SeverityAnti-PatternWhy It FailsFix
HighSecurity through obscurityHidden URLs are discoverable via fuzzing, logs, or sourceAuthentication + authorization on all endpoints
HighTrusting client headersX-Forwarded-For, X-Is-Admin are trivially forgedServer-side identity verification
HighClient-side authorizationJavaScript checks are bypassed by any HTTP clientServer-side permission checks on every handler
HighShared secrets across envsStaging breach compromises productionPer-environment secrets via secret manager
CriticalIgnoring crypto errors_, _ = encrypt(data) silently proceeds unencryptedAlways check errors — fail closed, never open
CriticalRolling your own cryptoCustom encryption hasn't been analyzed by cryptographersUse crypto/aes GCM, golang.org/x/crypto/argon2

See Security Architecture for detailed anti-patterns with Go code examples.

Cross-References

See samber/cc-skills-golang@golang-database, samber/cc-skills-golang@golang-safety, samber/cc-skills-golang@golang-observability, samber/cc-skills-golang@golang-continuous-integration skills.

  • → See samber/cc-skills-golang@golang-continuous-integration skill for automated AI-driven code review in CI using these guidelines

Additional Resources

Files

references/cryptography.md

Cryptography Security Rules

Cryptography vulnerabilities threaten confidentiality and integrity of sensitive data.

Rules:

  1. TLS MUST use 1.2+.

  2. NEVER use DES, RC4, MD5, or SHA1 for security purposes.

  3. SSH host keys MUST be verified — NEVER use InsecureIgnoreHostKey.

  4. Passwords MUST be hashed with Argon2id (preferred) or bcrypt.

  5. Security-critical randomness MUST use crypto/rand.

Table of Contents

  • Algorithm Selection Guide

    • Key Size Requirements

  • Key Rotation Pattern

  • Common Cryptographic Mistakes

    • Mistake 1: AES-ECB reveals patterns — High

    • Mistake 2: Reusing nonces — Critical

    • Mistake 3: Non-constant-time comparison for secrets — Medium

  • Insecure TLS Configuration — High

  • DES Encryption — High

  • Insecure SSH Host Key Verification — High

  • MD5 Hash — High

  • RC4 Cipher — High

  • SHA1 Hash — Medium

  • Weak Cryptographic Algorithms — Medium

  • Insufficient Key Strength — Medium

  • Weak Random Number Generators — High

  • Weak TLS Versions — High

  • Password Hashing — High

  • CWE References

Algorithm Selection Guide

Choose the right algorithm for the job — using the wrong primitive (e.g. SHA256 for passwords) is as dangerous as using a broken one:

Use CaseRecommendedAvoidWhy
Symmetric encryptionAES-256-GCM, ChaCha20-Poly1305DES, 3DES, AES-ECB, RC4ECB reveals patterns; DES/RC4 are broken
Password hashingArgon2id (preferred), bcrypt, scryptMD5, SHA-1, plain SHA-256Fast hashes enable brute-force; memory-hard functions resist GPU attacks
Message authenticationHMAC-SHA256, Poly1305HMAC-MD5, HMAC-SHA1MD5/SHA1 have known collision weaknesses
Digital signaturesEd25519, ECDSA P-256RSA-PKCS1v1.5PKCS1v1.5 has padding oracle vulnerabilities
Key exchangeX25519, ECDH P-256Static RSA key transportForward secrecy requires ephemeral keys
Random generationcrypto/randmath/randmath/rand output is predictable
TLSTLS 1.2+ (prefer 1.3)TLS 1.0, 1.1, SSLKnown attacks (BEAST, POODLE) on older versions
Key Size Requirements
AlgorithmMinimum Key SizeRecommended
RSA2048 bits4096 bits
AES128 bits256 bits
ECDSAP-256 (128-bit security)P-256 or Ed25519

Key Rotation Pattern

Keys should be rotated periodically. Use envelope encryption so rotating the Key Encryption Key (KEK) doesn't require re-encrypting all data:

// Envelope encryption: encrypt data with a DEK, encrypt DEK with KEK
func EnvelopeEncrypt(kek, plaintext []byte) (encryptedDEK, ciphertext []byte, err error) {
    // 1. Generate random Data Encryption Key
    dek := make([]byte, 32)
    if _, err := rand.Read(dek); err != nil {
        return nil, nil, err
    }

    // 2. Encrypt data with DEK
    ciphertext, err = EncryptAESGCM(dek, plaintext)
    if err != nil {
        return nil, nil, err
    }

    // 3. Encrypt DEK with KEK
    encryptedDEK, err = EncryptAESGCM(kek, dek)
    if err != nil {
        return nil, nil, err
    }

    return encryptedDEK, ciphertext, nil
}

func EnvelopeDecrypt(kek, encryptedDEK, ciphertext []byte) ([]byte, error) {
    dek, err := DecryptAESGCM(kek, encryptedDEK)
    if err != nil {
        return nil, err
    }
    return DecryptAESGCM(dek, ciphertext)
}

func EncryptAESGCM(key, plaintext []byte) ([]byte, error) {
    block, err := aes.NewCipher(key)
    if err != nil { return nil, err }
    aead, err := cipher.NewGCM(block)
    if err != nil { return nil, err }
    nonce := make([]byte, aead.NonceSize())
    if _, err := rand.Read(nonce); err != nil { return nil, err }
    return aead.Seal(nonce, nonce, plaintext, nil), nil
}

func DecryptAESGCM(key, ciphertext []byte) ([]byte, error) {
    block, err := aes.NewCipher(key)
    if err != nil { return nil, err }
    aead, err := cipher.NewGCM(block)
    if err != nil { return nil, err }
    nonceSize := aead.NonceSize()
    if len(ciphertext) < nonceSize {
        return nil, errors.New("ciphertext too short")
    }
    return aead.Open(nil, ciphertext[:nonceSize], ciphertext[nonceSize:], nil)
}

When the KEK is rotated, only re-encrypt the DEKs (small), not the data (potentially large).

Common Cryptographic Mistakes

Mistake 1: AES-ECB reveals patterns — High

ECB encrypts each block independently — identical plaintext blocks produce identical ciphertext blocks, revealing data structure:

// Bad — ECB mode reveals patterns in structured data
block, _ := aes.NewCipher(key)
// Using block.Encrypt directly = ECB mode

// Good — GCM provides authenticated encryption
aead, err := cipher.NewGCM(block) // randomized, authenticated
if err != nil {
    return nil, err
}
nonce := make([]byte, aead.NonceSize())
if _, err := rand.Read(nonce); err != nil {
    return nil, err
}
ciphertext := aead.Seal(nonce, nonce, plaintext, nil)
Mistake 2: Reusing nonces — Critical

A nonce reuse with AES-GCM completely breaks confidentiality and authentication:

// Bad — static or reused nonce
nonce := []byte("fixed_nonce!") // catastrophic with GCM

// Good — random nonce per encryption
nonce := make([]byte, 12) // 96-bit for GCM
if _, err := rand.Read(nonce); err != nil {
    return nil, err
}
Mistake 3: Non-constant-time comparison for secrets — Medium

Comparing secrets with == short-circuits on the first differing byte, leaking timing information. See Network/Web Security — Observable Timing for constant-time comparison patterns using crypto/subtle.

Insecure TLS Configuration — High

Using insecure TLS configurations can expose your application to man-in-the-middle attacks.

Bad:

transport := &http.Transport{
    TLSClientConfig: &tls.Config{
        InsecureSkipVerify: true, // DON'T: verify certificates
    },
}

Good:

import "crypto/tls"

func secureConfig() *tls.Config {
    return &tls.Config{
        MinVersion:       tls.VersionTLS12,
        CurvePreferences: []tls.CurveID{tls.X25519, tls.CurveP256},
    }
}

DES Encryption — High

DES is cryptographically broken.

Bad:

import "crypto/des"
block, _ := des.NewCipher(key) // DON'T: broken

Good:

import "crypto/aes"
block, _ := aes.NewCipher(key)     // OK: AES
cipher.NewGCM(block)              // OK: GCM for auth

Insecure SSH Host Key Verification — High

Bad:

import "golang.org/x/crypto/ssh"
&ssh.ClientConfig{
    HostKeyCallback: ssh.InsecureIgnoreHostKey(), // DON'T
}

Good:

import "golang.org/x/crypto/ssh"
&ssh.ClientConfig{
    HostKeyCallback: ssh.FixedHostKey(publicKey),
}

MD5 Hash — High

MD5 is collision-prone and weak for security.

Bad:

import "crypto/md5"
hash := md5.Sum([]byte(data)) // DON'T: weak

Good:

// For password hashing:
import "golang.org/x/crypto/argon2"
hash := argon2.IDKey([]byte(pw), salt, 3, 64*1024, 4, 32)

// Or bcrypt (simpler API, no salt management):
import "golang.org/x/crypto/bcrypt"
hash, err := bcrypt.GenerateFromPassword([]byte(pw), bcrypt.DefaultCost)
if err != nil {
    return nil, err
}

// For general-purpose hashing (not passwords):
import "crypto/sha256"
digest := sha256.Sum256(data)

RC4 Cipher — High

RC4 is cryptographically broken.

Bad:

import "crypto/rc4"
cipher, _ := rc4.NewCipher(key) // DON'T: broken

Good:

import "crypto/cipher"
import "crypto/aes"
aead, _ := cipher.NewGCM(block) // OK: AES-GCM

// Or ChaCha20:
import "golang.org/x/crypto/chacha20poly1305"
aead, _ := chacha20poly1305.New(key)

SHA1 Hash — Medium

SHA1 provides insufficient collision resistance.

Bad:

import "crypto/sha1"
hash := sha1.Sum(data) // DON'T: weak

Good:

import "crypto/sha256"
hash := sha256.Sum256(data)

Weak Cryptographic Algorithms — Medium

Bad:

import "crypto/hmac"
import "crypto/md5"
mac := hmac.New(md5.New, key) // DON'T: HMAC-MD5

Good:

import "crypto/sha256"
mac := hmac.New(sha256.New, key)

Insufficient Key Strength — Medium

RSA keys smaller than 2048 bits are insufficient.

Bad:

import "crypto/rsa"
key, _ := rsa.GenerateKey(rand.Reader, 1024) // DON'T: too weak

Good:

key, _ := rsa.GenerateKey(rand.Reader, 4096) // OK: 2048+ bits

Weak Random Number Generators — High

math/rand is predictable, never use for security.

Bad:

import "math/rand"
bytes := make([]byte, 16)
rand.Read(bytes) // DON'T: predictable

Good:

import "crypto/rand"
_, err := rand.Read(bytes) // OK: cryptographically secure

Weak TLS Versions — High

TLS 1.0 and 1.1 have known vulnerabilities.

Bad:

import "crypto/tls"
&tls.Config{MinVersion: tls.VersionTLS10} // DON'T

Good:

&tls.Config{MinVersion: tls.VersionTLS12} // OK

Password Hashing — High

Don't use MD5, SHA1, or single-iteration hashes for passwords.

Bad:

import "crypto/sha256"
hash := sha256.Sum256([]byte(password)) // DON'T: too fast

Good:

// Argon2id (preferred) — memory-hard, resists GPU attacks:
import "golang.org/x/crypto/argon2"
key := argon2.IDKey([]byte(password), salt, 3, 64*1024, 4, 32)

// Or bcrypt (simpler API, widely supported):
import "golang.org/x/crypto/bcrypt"
hash, err := bcrypt.GenerateFromPassword([]byte(pw), bcrypt.DefaultCost)
if err != nil {
    return nil, err
}

// Or PBKDF2 with 600,000+ iterations (Go 1.24+ stdlib):
import "crypto/pbkdf2"
key, err := pbkdf2.Key(sha512.New, password, salt, 600_000, 32)
if err != nil {
    return err
}

// Or scrypt:
import "golang.org/x/crypto/scrypt"
key, err := scrypt.Key([]byte(password), salt, 32768, 8, 1, 32)
if err != nil {
    return err
}

For Go 1.24+, prefer stdlib crypto/hkdf, crypto/pbkdf2, and crypto/sha3. Use golang.org/x/crypto/... fallbacks only for modules targeting older Go versions or for algorithms still outside the standard library.

CWE References

  • CWE-327: Use of a Broken or Risky Cryptographic Algorithm

  • CWE-331: Insufficient Entropy

  • CWE-326: Inadequate Encryption Strength

  • CWE-295: Improper Certificate Validation

  • CWE-330: Use of Insufficiently Random Values

  • CWE-916: Use of Password Hash With Insufficient Computational Effort

Requirements and compatibility

Written for: Claude Code, OpenAI Codex

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Claude Code frontmatter

The author says: Designed for Claude Code, Codex or similar harness, and for projects using Golang.

Security

What our scanner noticed· Medium risk

  • References to credential files

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
samber
Publisher
Samuel Berthe (Community)
Distributed by
Samuel Berthe
Source
samber/cc-skills-golang · skills/golang-security · commit bb1d43d
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by samber or Samuel Berthe.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download golang-security.zip