Overview SAST scans an application’s source code at rest to catch insecure patterns before the app ever runs, while DAST attacks a running application from the outside to find exploitable flaws in its live behavior. Teams use both because each catches vulnerability classes the other structurally cannot see. Comparison Diagram SASTsource code, no executionfunction login(u,p) { const q = "SELECT..+p"; db.exec(q);}reads code, flags line 128e.g. unsanitized SQL concatDASTrunning app, black-boxLive App/login endpointPOST u=' OR 1=1--sends live requests, observes responsee.g. auth bypass returned Comparison Table Aspect SAST DAST What it examines Source code, bytecode, or binaries at rest A running, deployed application from outside Access level White-box — full visibility into code internals Black-box — only sees inputs and outputs like an attacker When in SDLC Early, during coding and in CI on every commit Later, once a build is deployed to a test or staging environment Environment needed None — analyzes files directly, no app needs to run A live, reachable instance of the application Vulnerability classes found Insecure code patterns: SQL string building, hardcoded secrets, unsafe deserialization Exploitable runtime behavior: auth bypass, injection responses, misconfigured headers Language/stack dependency Tied to the language and framework being parsed Language-agnostic — probes over HTTP/HTTPS regardless of stack False positive tendency Higher — flags patterns that may not be reachable or exploitable Lower — findings are confirmed by actual exploit attempts Remediation output Exact file and line number to fix Vulnerable URL, parameter, and request/response evidence Key Differences SAST inspects source code without running it; DAST attacks a live instance without seeing its internals SAST fits early into CI pipelines per-commit; DAST needs a deployed build to test against SAST pinpoints the exact line number; DAST reports the vulnerable endpoint and payload SAST is prone to false positives from unreachable code paths; DAST confirms via actual exploitation SAST misses runtime configuration flaws that DAST catches, like missing security headers or session issues When to Use Each SAST ...

Overview An IDS and an IPS both inspect network traffic for malicious patterns, but they sit in different places and react differently once a threat is found. An IDS works out-of-band, watching a copy of traffic and raising alerts, while an IPS works inline, sitting directly in the traffic path so it can block the packets itself. The distinction matters because it determines whether a false positive causes a noisy log entry or an actual outage. ...

Overview SSL and TLS are cryptographic protocols that secure data in transit between clients and servers, but SSL is the deprecated predecessor while TLS is its actively maintained successor. Every SSL version is now broken or prohibited, yet the term “SSL” persists in everyday usage even though modern connections actually negotiate TLS. Comparison Diagram SSLTLSSSL 2.0 (1995)broken by DROWNSSL 3.0 (1996)broken by POODLEall versions prohibitedTLS 1.0 (1999)TLS 1.1 (2006)TLS 1.2 (2008)widely deployedTLS 1.3 (2018)current standardtime →deprecated / prohibitedactively maintained Comparison Table Aspect SSL TLS Origin Developed by Netscape starting in 1995 Standardized by the IETF in 1999 as SSL’s successor Versions released SSL 2.0, SSL 3.0 (SSL 1.0 never shipped) TLS 1.0, 1.1, 1.2, 1.3 Handshake process Full handshake only, with weaker key exchange options Streamlined handshake; TLS 1.3 cuts a round trip and defaults to forward secrecy Cipher suite support Permits weak ciphers like RC4, DES, and export-grade crypto Mandates modern AEAD ciphers (AES-GCM, ChaCha20-Poly1305); weak ciphers dropped entirely in 1.3 Known vulnerabilities POODLE broke SSL 3.0; DROWN broke SSL 2.0 BEAST and CRIME hit early TLS 1.0 but were patched in later versions Current status All versions formally deprecated and prohibited (RFC 7568) TLS 1.2 and 1.3 are the current standards; 1.0/1.1 also deprecated Everyday terminology “SSL certificate” and “SSL/TLS” persist as colloquial shorthand The protocol actually negotiated by nearly every modern HTTPS connection Key Differences SSL is the obsolete predecessor; TLS is the actively maintained successor protocol TLS 1.3’s handshake trims a round trip compared to SSL’s full handshake SSL still permits weak ciphers like RC4; TLS mandates modern AEAD ciphers The label “SSL certificate” survives in marketing even though browsers negotiate TLS SSL 3.0 was broken by POODLE, forcing its complete deprecation When to Use Each SSL ...

Overview Hashing and encryption both scramble data into something unreadable, but they solve different problems: hashing is a one-way function used to verify that data hasn’t changed, while encryption is a reversible process used to keep data secret from unauthorized parties. Mixing them up — like encrypting passwords instead of hashing them — is a common and dangerous mistake. Comparison Diagram HashingEncryptionInput (any length)Hash FunctionDigest (fixed length)irreversible, no keyPurpose: integrity & verificationPlaintextEncrypt (+ key)CiphertextDecrypt (+ key)Plaintext (recovered)Purpose: confidentiality Comparison Table Aspect Hashing Encryption Core operation Transforms input into a fixed-length digest Transforms plaintext into ciphertext Reversibility One-way; original input cannot be recovered Two-way; ciphertext decrypts back to plaintext Key requirement No key needed for a standard hash function Requires a secret key (or key pair) Output size Fixed-length digest regardless of input size Ciphertext length scales with plaintext size Determinism Same input always produces the same digest Same plaintext yields different ciphertext each run via IV/nonce Primary goal Integrity verification and data identification Confidentiality of data Main failure mode Collision: two inputs producing the same digest Key compromise, exposing all encrypted data Typical use cases Password storage, checksums, digital signatures Securing data at rest and in transit Key Differences Hashing is one-way; encryption is designed to be reversible with the correct key. Encryption always requires a secret key; standard hashing needs none. A hash always produces a fixed-length digest, no matter how large the input is. Hashing protects integrity; encryption protects confidentiality. A hash function must resist collisions; a cipher must resist key or plaintext recovery. When to Use Each Hashing ...

Overview Symmetric encryption uses a single shared secret key for both locking and unlocking data, making it fast but dependent on securely distributing that key beforehand. Asymmetric encryption uses a mathematically linked key pair — public and private — solving the distribution problem at the cost of heavier computation. Comparison Diagram SymmetricAsymmetricAliceBobsame keyshared secretlySenderReceiverpublic key(shared openly)private key(kept secret)encrypted withpublic key1 key, both directions2 keys, one direction each Comparison Table Aspect Symmetric Encryption Asymmetric Encryption Key setup One shared secret key generated for both parties Mathematically linked key pair: public key and private key Key distribution Requires a secure channel to exchange the key beforehand Public key can be freely published; private key never leaves its owner Encryption operation Same key encrypts the plaintext Sender encrypts using the recipient’s public key Decryption operation Same key decrypts the ciphertext Recipient decrypts using their own private key Performance Fast, low CPU overhead, suited to large volumes of data Computationally expensive, orders of magnitude slower Key scalability Number of keys needed grows quadratically with participants Each participant needs only one key pair regardless of participant count Common algorithms AES, ChaCha20, 3DES RSA, ECC, Diffie-Hellman Typical use case Bulk data encryption: disks, files, VPN tunnels Key exchange, digital signatures, certificate/identity verification Key Differences Symmetric uses a single shared key; asymmetric uses a key pair of public and private keys Symmetric is far faster, making it practical for encrypting large payloads Asymmetric eliminates the key distribution problem since the public key can be shared openly Real-world protocols like TLS use a hybrid approach, using asymmetric encryption to exchange a symmetric session key Only asymmetric keys support digital signatures for authenticity and non-repudiation When to Use Each Symmetric Encryption ...

Overview Model quantization and model pruning are both techniques for shrinking neural networks and speeding up inference, but they compress different things. Quantization keeps every weight but represents each one with fewer bits (e.g. FP32 → INT8), while pruning keeps full precision but removes weights, neurons, or channels judged unimportant. The two techniques are complementary and are frequently chained together in a single compression pipeline. Comparison Diagram Model QuantizationBefore: FP32 (32-bit)0.482-1.0370.917-0.203quantizeAfter: INT8 (8-bit)61-132117-26Same 4 values, fewer bits each≈4× smaller, faster mathModel PruningBefore: dense networkpruneAfter: sparse (pruned)Fewer neurons & connectionskeptremoved Comparison Table Aspect Model Quantization Model Pruning Core mechanism Reduces numeric precision of weights/activations (e.g. FP32 → INT8/INT4) Removes individual weights, neurons, or channels judged low-importance What changes Same parameter count, smaller representation per value Fewer parameters; model becomes sparse or physically smaller Granularity Per-tensor, per-channel, or per-group bit-width choices Unstructured (single weights) vs structured (filters/channels/layers) When applied Post-training quantization (PTQ) or quantization-aware training (QAT) Iterative pruning during training or magnitude-based pruning after training, usually with fine-tuning Hardware/runtime requirement Needs low-precision kernel support (INT8 cores, TensorRT, XNNPACK) Unstructured pruning needs sparse-matrix kernels for real speedup; structured pruning runs on standard dense hardware Compression achieved Typically 2-4x size reduction (FP32→INT8); INT4 pushes further at higher accuracy risk Can reach 50-90% sparsity, but unstructured sparsity often doesn’t translate to real speedup without special hardware Accuracy impact & recovery Small accuracy drop, usually recovered via calibration or QAT Larger accuracy drop at high sparsity, recovered via iterative fine-tuning/retraining Combinability Often applied last, to shrink an already-pruned model further Often applied first, before the pruned model is quantized Key Differences Quantization changes each value’s bit-width; pruning changes the model’s parameter count. Realizing pruning’s theoretical speedup often requires sparse kernels, while quantization’s speedup comes from standard INT8 hardware support. Quantization degrades accuracy gradually and predictably; aggressive pruning risks a sharp accuracy cliff without fine-tuning. The two are commonly chained into a single compression pipeline, pruning first and quantizing the result. Structured pruning changes the model’s architecture shape; quantization never touches the architecture. When to Use Each Model Quantization ...

Overview Zero-shot and few-shot learning describe how much task-specific example data a model is given before it has to perform a task. Zero-shot relies solely on a task description, while few-shot conditions its predictions on a small set of labeled examples, usually trading a little setup cost for higher accuracy. Comparison Diagram Zero-ShotFew-ShotTask instructiononly(0 examples)Task instruction+ K examples123PretrainedModelPretrainedModelPredictionPredictionno task-specific datalearns from few examples Comparison Table Aspect Zero-Shot Learning Few-Shot Learning Core definition Model performs a task it was never explicitly shown examples for, guided only by natural-language instructions or class descriptions Model performs a task after being shown a small number (typically 1-100) of labeled examples at inference or fine-tuning time Examples provided at inference None — only a task description or prompt A handful of input-output pairs included in the prompt or used for fine-tuning Underlying mechanism Relies entirely on knowledge encoded during pretraining plus semantic alignment between labels and text Uses in-context learning or lightweight fine-tuning to infer the task pattern directly from the provided examples Labeling/data cost Effectively zero — no labeled data needed for the target task Low but nonzero — requires curating a small, representative set of examples Prompt/context length Short — just the instruction or class names Longer — instruction plus example pairs, consuming more context tokens Typical accuracy Lower and more variable, especially on niche or ambiguous tasks Generally higher and more stable since examples disambiguate intent Sensitivity to example choice Not applicable — there are no examples to choose High — accuracy can swing significantly with example selection, order, and count Common techniques Prompt engineering, CLIP-style embedding matching, instruction-tuned LLMs Few-shot prompting, meta-learning (e.g. MAML), lightweight fine-tuning or LoRA Key Differences Zero-shot uses no task examples at all, relying purely on pretrained knowledge and instructions Few-shot conditions the model on a small support set of labeled examples at inference time Few-shot generally achieves higher accuracy because examples disambiguate an otherwise vague instruction Zero-shot has zero labeling cost, while few-shot requires curating representative examples Few-shot performance is sensitive to example selection, a variable that zero-shot simply doesn’t have When to Use Each Zero-Shot Learning ...

Overview Fine-tuning and RAG (Retrieval-Augmented Generation) are two ways to make a large language model produce better, more relevant answers, but they intervene at different points in the pipeline. Fine-tuning permanently adjusts the model’s weights through additional training, while RAG leaves the model untouched and instead injects context by retrieving documents at query time. The choice matters because it determines how you update knowledge, control latency and cost, and trace where an answer came from. ...

Overview Generative and discriminative models represent two different answers to “what should a model actually learn from labeled data?” A generative model learns the full joint distribution of inputs and labels — effectively how each class produces its data — while a discriminative model learns only the boundary needed to tell classes apart, without modeling how the data itself was produced. That difference drives everything from data efficiency to whether the model can create new examples. ...

Overview BERT and GPT are both transformer-based language models, but they’re built from opposite halves of the transformer and trained for opposite jobs. BERT uses an encoder trained to fill in masked words using context from both directions, making it suited to understanding text, while GPT uses a decoder trained to predict the next word from only what came before, making it suited to generating text. Comparison Diagram BERT GPT Bidirectional Encoder Autoregressive Decoder the cat [MASK] on mat sees full sentence context (left + right) to fill the mask -> classification, embeddings, NER the cat sat on mat ? each token sees only itself + prior tokens (causal mask) -> generation, chat, completion Comparison Table Aspect BERT GPT Architecture Encoder-only transformer stack Decoder-only transformer stack Pretraining objective Masked language modeling: predict randomly hidden tokens, plus next-sentence prediction Causal language modeling: predict the next token given all prior tokens Attention pattern Bidirectional self-attention; every token attends to the full sequence Causal (masked) self-attention; each token attends only to itself and earlier tokens Output generation One contextual embedding per input token, produced in a single forward pass Text generated autoregressively, one token at a time, each output fed back as input Typical adaptation Fine-tuned with a task-specific head on top of the pretrained encoder Adapted via prompting, instruction tuning, or fine-tuning to continue text Primary use cases Classification, named entity recognition, semantic search, sentence embeddings Open-ended generation, chat, code completion, summarization Inference cost per query Fixed: one pass regardless of desired output Scales with number of generated tokens, each requiring a forward pass Key Differences BERT’s encoder attends to both left and right context; GPT’s decoder attends only to prior tokens. BERT trains on masked language modeling; GPT trains on next-token prediction. BERT produces embeddings in a single pass; GPT produces text through autoregressive decoding. BERT is optimized for understanding tasks; GPT is optimized for generation tasks. When to Use Each BERT ...