# CISSP Domain 8 — build security in, then prove the build

Source: https://ai.techclick.in/blog_cissp_d8_software_security
Markdown: https://ai.techclick.in/blog_cissp_d8_software_security.md
Publisher: Techclick Infosec Pvt Ltd

CISSP Domain 8 (10%): put security in the SDLC, pick code review vs SAST vs DAST vs SCA, map OWASP Top 10:2025, and prove a release with SBOM plus signed provenance.

Quick answer

   Domain 8 is not “write secure code.” It is  put security in the lifecycle , then  pick the test that can see the flaw , then  prove what you shipped . Requirements and a threat model come first. Human  code review  reads intent and business logic.  SAST  reads source without running it.  DAST  attacks a running build.  SCA  inventories libraries. An  SBOM  tells you where a CVE lives;  signing / SLSA provenance  tells you the binary came from  your  pipeline. OWASP Top 10:2025 names the failure classes — Broken Access Control is still first; Software Supply Chain Failures is now A03. A WAF is not a parameterized query. Input validation is not authorization.

   Say this out loud

   I do not bolt a scanner on Friday. I put a control in the phase that can still change the design. Review sees logic. SAST sees source. DAST sees runtime. SCA sees the bill of materials. I do not ship what I cannot name and sign.

## 1. Why Domain 8 matters

 ISC2 weights  Software Development Security  at  10%  of the CISSP CAT (exam outline effective 15 April 2024; this domain dropped from 11%). The official verbs are five: integrate security in the SDLC, apply controls in the development ecosystem, assess whether those controls work, assess acquired software, and apply secure coding guidelines. The exam — and a real change-advisory board — punish the same mistake: treating security as a test phase.

 That is the ticket in this lesson. A payment API ships because “SAST was green.” The flaw is an IDOR. SAST never executed the request. DAST was skipped “to make the window.” There is no SBOM when the next library CVE lands. The scanner did not fail. The  program  did.

   Hero · code goes through gates, not around them

   Notice: the developer never talks to production. The pipeline does — and only if scan, sign, and provenance all pass.

#### Manager lens

 When is security allowed to stop a release, who owns residual risk on a known vuln, and what evidence (SBOM, sign-off, exception) exists after go-live.

#### Engineer lens

 Which tool can actually see this class of flaw, where it sits in CI/CD, and what a green gate is allowed to prove — and what it is not.

   Official outline (what this page covers)

    8.1  SDLC methods (Agile, Waterfall, DevOps, DevSecOps, SAFe), maturity models (CMM, SAMM), operations, change management, Integrated Product Team.  8.2  Languages, libraries, tools, IDE, runtime, CI/CD, configuration management, repositories, SAST / DAST / SCA / IAST.  8.3  Audit of changes, risk analysis.  8.4  COTS, open source, third-party, managed and cloud services.  8.5  Source-level weaknesses, API security, secure coding, software-defined security. Source:  ISC2 CISSP Certification Exam Outline .

   Hard words before the runbook

    Shift-left  — move a control to the earliest phase that can still change the design, not “run every tool on commit.”

    Code review  — a human (or pair) reads source for intent, authorization, and business logic. White-box. Does not prove runtime.

    SAST  — static analysis of source or bytecode without executing the app.

    DAST  — dynamic testing of a running application, usually as a black box.

    IAST  — instrumentation inside a running app; sees both code paths and live requests.

    SCA  — software composition analysis: inventory of third-party components and known CVEs / licences.

    SBOM  — a list of what is in a build, including transitive dependencies. Visibility, not integrity.

    Provenance / SLSA  — evidence of  how  and  where  the artifact was built. Signing is how you verify it.

## 2. Mental model — SDLC, methods, maturity

 Hold three parts. Interviews fail when people treat “secure SDLC” as a slogan, treat SAMM as CMM, or treat DevOps speed as a reason to skip a gate.

   Journey · design, code, review, test, release

   Read left to right. Review sits before Test. If the only security activity is a DAST run on Friday, you already lost the cheap defects.

### Part 1 · security has a job in every phase

 An SDLC is just the order in which you turn an idea into running software and then retire it. Domain 8’s claim is narrower:  each phase has a security deliverable , or defects become 10–100× more expensive to fix. NIST’s Secure Software Development Framework (SP 800-218) groups the work into four outcomes, not a vendor pipeline:  Prepare the Organization (PO) ,  Protect the Software (PS) ,  Produce Well-Secured Software (PW) ,  Respond to Vulnerabilities (RV) .

   Flow 1 · SDLC phase and the security job

       Secure SDLC phases with the security activity that belongs in each

- If the activity is missing, the defect belongs to this phase Requirements abuse cases, CIA Design threat model Code review + SAST Build SCA + SBOM Test DAST / IAST Release sign + verify Operate and maintain (8.1) Patch, secret rotation, dependency refresh Change management on every production delta Retire / dispose Revoke keys, wipe images, close APIs An abandoned endpoint is still an asset NIST SSDF outcomes sit across this line, not in one box PO prepare people and env · PS protect source and artifacts · PW produce securely · RV respond to vulns SP 800-218 is a practice set you add to whatever SDLC you already run. Read left → right, then the two ops boxes. The FIRST answer on a new feature is almost always Requirements or Design, not a late DAST ticket. ### Part 2 · the method changes when the gate fires, not whether it exists Outline 8.1 names five methods. Waterfall is sequential — security that waits for a UAT phase is late by construction. Agile puts work in sprints — security belongs in the definition of done, not in a hardening sprint after demo. DevOps is CI/CD speed. DevSecOps is the same pipeline with security as an automated gate and a shared responsibility, not a throw-over-the-wall team. SAFe scales Agile across trains — security has to live at team, program, and portfolio, or one ART ships around the control. An Integrated Product Team (IPT) is the outline’s name for the cross-functional group — developer, tester, security, operations, business — that owns the product. Security as a visitor at sprint 11 is not an IPT. Method Where security usually dies Manager move Waterfall Security testing after code-complete Security requirements and design review are exit criteria for those phases. Agile “We’ll harden next sprint” Abuse cases and review in the definition of done. No story is done if the gate is red. DevOps Pipeline has no fail-closed security job Fund the gates. Speed without a stop is just faster defect delivery. DevSecOps Gates exist but are warning-only Severity policy: critical CVE / secret / unsigned artifact blocks merge or deploy. SAFe One team opts out of the ART standard Portfolio non-functional requirement. Local waivers expire and are signed. ### Part 3 · maturity models are not interchangeable Outline 8.1 names CMM and SAMM . CMM / CMMI measures whether your process is repeatable (Level 1 chaotic through Level 5 optimizing). It is not a security catalogue. OWASP SAMM is prescriptive: it tells you which security practices to grow, by business function, at a maturity you choose. Well-known CBK also contrasts BSIMM , which is descriptive — it observes what real firms do and scores you as a benchmark. SAMM says “do this next.” BSIMM says “here is what peers actually do.” Do not mix the verbs on the exam. Classic miss Calling CMMI Level 3 “secure software.” Process maturity without secure-coding standards, review, and pipeline gates is a well-run factory that still ships injection. SAMM (or an equivalent AppSec program) is the security overlay. CMM is the factory floor. Say this out loud Waterfall, Agile, and DevOps change the calendar. They do not delete the job. SAMM prescribes security practices. CMM grades process discipline. BSIMM benchmarks what others already do. ## 3. Decision flow — review vs DAST vs SCA Draw this before you buy a scanner or write a standard. First decide what field you must see . Source? A running request? A library name? Human intent? Then pick the control that can see that field. Then place it in the earliest pipeline stage that still has that field. Feel · two paths from one question Path A is “read the source.” Path B is “attack the running build.” Domain 8 lives on both. The trap is pretending one path covers the other. Flow 2 · What must you be able to see? Decision flow from the question you are asking to code review, SAST, DAST, IAST, or SCA What question are you trying to answer? Need the running app? no · source / inventory yes · execute it Human intent / logic? authz, money, workflow Code review · pair · IPT Pattern in source? SAST · secrets Which library? SCA · SBOM Need code + request? instrumented QA IAST both views DAST black-box live Not a substitute WAF · more SAST tuning · “we have CI” Read the diamond first. Code review is the answer when the flaw is intent (IDOR design, double-spend, missing authz). DAST is the answer when the flaw only appears while the app runs. SCA never reads your if-statement. Code review vs DAST — the exam contrast Code review is white-box and early. A reviewer can see that accountId from the client is trusted, that a coupon can apply twice, that a TODO disables authz, that an AI assistant pasted a hardcoded token. Review cannot prove a misconfigured TLS cipher on the staging host. DAST is black-box and later. It sends real requests to a running build and sees auth bypass, XSS that only appears after a template renders, default creds, and directory listings. DAST cannot read the source, so it is weak on hidden business logic and on code paths the crawler never hit. If the stem says “logic,” “intent,” “design,” or “peer,” pick review. If it says “running,” “staging,” “misconfiguration,” or “as an outsider,” pick DAST. Layer them. Do not retune the one you already have. ## 4. How to choose tests and OWASP controls Outline 8.2 names the test family explicitly: SAST, DAST, SCA, IAST . Outline 8.5 names the coding problem: source-level weaknesses, API security, secure coding practices, software-defined security. Use the first table to pick a test. Use the second to pick the control that actually closes the OWASP class. You need to know… Pick When it runs It will miss Does this function authorize the owner? Can a coupon fire twice? Code review (peer, pair, IPT) Before merge. Cheapest. Runtime config, environment drift, paths nobody read. Is there a sink that concatenates SQL? A secret in source? SAST Commit / PR. No running app. Authz that is logically wrong but syntactically fine. Live misconfig. Which libraries, including transitive, have a CVE or a bad licence? SCA + emit SBOM Build / merge. Needs lockfiles. Your own business logic. Zero-days not yet in the feed. What happens if an outsider hits the running app? DAST Deployed QA / staging. Dead code, unauthenticated-only crawl gaps, design intent. Which line of code handled this live request? IAST Instrumented test / QA. Anything the test suite never exercised. Agents add cost. What if we smash unexpected inputs for hours? Fuzzing (well-known CBK; sits with DAST-family) After a build exists. Authorization policy. Needs a harness. OWASP Top 10: 2025 is the current awareness list. Two 2025 moves matter on this exam: A03 Software Supply Chain Failures is now its own category, and A10 Mishandling of Exceptional Conditions is new. Injection dropped to A05 — it did not become safe. OWASP Top 10:2025 What it looks like in a ticket Control that actually closes it A01 Broken Access Control Change accountId / role and see another tenant (IDOR). Server-side authorization on every object. Deny by default. Review the check — scanners often miss a missing if. A02 Security Misconfiguration Default creds, directory listing, debug left on, cloud bucket public. Hardened baseline + DAST / config scan of the running stack. SAST cannot see the host. A03 Software Supply Chain Failures Dependency confusion, poisoned package, unsigned build, missing SBOM. Pinned hashes, private registry first, SCA, SBOM, signed provenance, verify before deploy. A04 Cryptographic Failures Home-grown crypto, TLS 1.0, secrets in source. Standard libraries, current TLS, secret scan + vault. Not “we hash passwords” as a slogan. A05 Injection "SELECT * FROM users WHERE name='" + input + "'" Parameterized queries / prepared statements. Allowlist where you must interpolate. A WAF is a seatbelt, not the fix. A06 Insecure Design No threat model. Feature cannot be made safe later. Threat model and abuse cases in Design. You cannot SAST your way out of a missing control. A07 Authentication Failures Credential stuffing, session fixation, missing MFA on the admin API. Proven auth library, MFA, session hygiene. Test it with DAST + review of the session code. A08 Software or Data Integrity Failures Auto-update without signature, insecure CI, deserialized untrusted blob. Sign artifacts, lock the pipeline, verify on install. Integrity is not “we have backups.” A09 Logging and Alerting Failures Login failures not logged; alert never fires. Log authz denials and admin actions; alert on them. Logging is not a compliance checkbox. A10 Mishandling of Exceptional Conditions Catch-all returns a stack trace; fail-open on auth error. Fail closed. Generic errors to the user. Review exception paths — DAST may only see the 500. A05 — the one-line contrast the exam loves UNSAFE db.query("SELECT * FROM users WHERE name='" + user + "'") SAFE db.query("SELECT * FROM users WHERE name = ?", [user]) The unsafe line mixes code and data. The safe line binds input as a value. Encoding output in the right context (HTML, URL, JS) is the sibling control for XSS. Neither is “a longer denylist of words.” Input validation is not authorization An IDOR request is often well-formed: an integer, a UUID, a JSON body that passes the schema. A01 is “does this subject own that object?” That check lives on the server after authentication. Tightening the regex does not close it. This is why code review of the authorization path beats another DAST crawl that never guesses the other tenant’s id — and why a DAST that does guess it still cannot tell you why the check is missing. ### APIs and software-defined security (8.5) API security on this domain is the same judgment with a smaller surface: authenticate the caller, authorize the object, validate the schema, rate-limit, and do not leak stack traces. Software-defined security is security expressed as code — policy-as-code, infrastructure-as-code scans, pipeline gates that fail closed. If the control only exists as a wiki page, it is not software-defined. ### AI-assisted coding — official Domain 8 note ISC2 now interweaves AI across the eight domains. For Domain 8 the official point is narrow: AI coding assistants can emit insecure snippets and “hallucinated” dependencies. Treat the model as an untrusted author. The control set does not change: peer review, SAST, secret scanning, SCA for packages the model invented. Banning the tool is not the BEST answer; shipping its output ungated is not due care. NIST SP 800-218A is the SSDF community profile for generative-AI development — same four groups, extra tasks for models and training data. ## 5. Runbook — design, gate, acquire This is not a vendor console path. It is the Domain 8 operating path you walk on a new service, a new library, or a Copilot-heavy team. Each side cites one primary source. ### Side A · design the requirement (shift-left) Primary source: NIST SP 800-218, SSDF v1.1 — Prepare (PO) and Produce (PW), plus outline 8.1. #### Write security requirements with the story Who may call this API? What is the object owner? What must fail closed? If the story has no abuse case, it is not ready for design. This is the FIRST move on a new feature stem.

- #### Threat-model the design before code STRIDE or a lighter data-flow sketch is enough. Insecure Design (A06) is the class you close here. A scanner will not invent a missing control.

- #### Stand up an Integrated Product Team Developer, reviewer, security, QA, operations, product. Security as a visitor after demo is not 8.1.

- #### Lock change management Production deltas — including “tiny” hotfixes and pipeline YAML — go through the same review and logging (8.1, 8.3). Emergency changes get a retroactive ticket the same day, not a shrug.

### Side B · gate the ecosystem

 Primary source: ISC2 outline 8.2 and  OWASP SAMM  (Verification + Implementation practices).

- #### Harden the place code is written IDE plugins catch secrets early. Repositories enforce signed commits or at least protected branches and required reviews. Language and library choices are an 8.2 control — memory-unsafe C for a parse-heavy internet service is a risk decision, not a taste.

- #### On every pull request: review + SAST + secret scan A human reads authorization and business logic. SAST reads sinks and sources. Neither replaces the other. AI-authored diffs get the same review, not a lighter one.

- #### On every build: SCA, SBOM, fail closed on policy Pin versions and hashes. Prefer the internal registry so a public package of the same name cannot win (dependency confusion). Emit an SBOM per artifact. Critical CVEs block merge. Warnings that never fail are decoration.

- #### On a running build: DAST / IAST, then sign Staging must look like production enough for DAST to be meaningful. Sign the artifact (Cosign / Sigstore or your enterprise equivalent) and keep the provenance with the SBOM. Configuration management (8.2) means the pipeline definition is reviewed like code.

### Side C · acquire software and prove the release

 Primary source: outline 8.4 and  SLSA  /  CISA SBOM .

- #### Assess before you import COTS, open source, third-party, managed services, and cloud (SaaS / PaaS / IaaS) are all 8.4. Ask for an SBOM, a vulnerability-handling SLA, where data lives, and who can push updates. A free library is still acquired software.

- #### Trust the pipeline, not the file share Only artifacts built by the official CI, with verified signatures and matching SBOMs, may reach production. A jar copied from a laptop is an A03 / A08 finding even if SCA was clean last month.

- #### Log the change and name residual risk 8.3 is auditing of changes plus risk analysis. A known CVE you chose to ship needs an owner, a date, and a compensating control. Silence is not acceptance.

   Green path — you finished Domain 8 work when

   The story had an abuse case. A reviewer saw the authz path. SAST and SCA ran and could fail the build. A running-environment test covered the live surface. The artifact has an SBOM and a signature you verified. Residual risk has a name and a date. Change is in the log.

## 6. Runtime path after go-live

 Release is not the end of 8.1. Operation, maintenance, and change management are on the outline. A CVE published on Thursday is an RV (Respond to Vulnerabilities) event: find the component, patch or mitigate, then fix the root cause so the next service does not repeat it.

   Proof · the SBOM and the signature are the care

   Notice: the list of what shipped is the diligence. The green check is only useful if it matches a signed artifact from your pipeline.

   Flow 3 · commit to production, then back again

       Runtime path from commit through signed deploy and vulnerability response

- Commit review + SAST Build SCA + SBOM Stage DAST / IAST Sign verify SLSA Produce log the change CVE / drift SBOM lookup → RV A new CVE or a failed control sends you back to Build — not to a war-room spreadsheet. Read left → right. The magenta box is why you kept the SBOM. Without inventory, Log4Shell-style response is archaeology. Domain 6 (assessment) still owns pen-tests, SOC reports, and coverage metrics. Domain 8 owns whether the product team can find and fix the same classes before an external tester does. If testers keep finding runtime auth-bypass after a clean SAST gate, the missing control is DAST/IAST — not a fiercer static ruleset. ## 7. Traps and proof Stem pattern What ISC2 is testing Engineer trap Manager move What do you do FIRST on a new feature / API? 8.1 sequencing. Design before tools. Stand up DAST or buy a WAF. Security requirements and a threat model. Then the gates. SAST is green; testers still find auth bypass. 8.2 — what each test can see. Tune SAST harder. Disable the findings. Add DAST/IAST against a running build. SAST cannot execute the request. Well-formed accountId reads another tenant. 8.5 A01 vs input validation. Tighten the regex / WAF. Server-side authorization. Review the check. Coupon applies twice; SAST and DAST are quiet. Code review vs scanners. More crawls. Ban the feature. Human review of the business-logic path (misuse case). Which of 200 services ship library X? 8.4 / A03 visibility. SSH to boxes. Hope the WAF holds. Query the SBOM. If you have none, that is the finding. Catch CVEs before merge. Shift-left placement. Annual pen-test. DAST in prod. SCA on the build, fail closed. Only official CI binaries in prod. Integrity / provenance. Scan more often. Sign artifacts; verify SLSA / provenance on deploy. CMM Level 3, so we are secure. 8.1 maturity-model verbs. Treat CMM as SAMM. CMM is process. SAMM (prescriptive) is the security overlay. BSIMM only benchmarks. Copilot / LLM wrote the patch. AI as untrusted author. Ban the tool, or trust it because “AI is trained on good code.” Same gates: review, SAST, secret scan, SCA for hallucinated packages. Pilot / interview proof checklist I can name a security deliverable for requirements, design, code, build, test, release, and operate.

- I can pick review vs SAST vs DAST vs SCA from one sentence of a stem.

- I can say why IDOR is authorization, not validation.

- I can say why parameterized queries beat a WAF for A05.

- I can tell SBOM (inventory) from a signature (integrity).

- I can tell SAMM (prescribe) from BSIMM (describe) from CMM (process).

- I did not quote a made-up “this subtopic is X% of the exam.” Domain 8’s official weight is 10% of the whole exam — that is the only percentage this page uses.

   Interview angle

    Weak:  “Domain 8 is OWASP and SAST.”  Strong:  “I put the control in the phase that can still change the design. Review sees logic. SAST sees source. DAST sees runtime. SCA plus an SBOM is how I survive the next library CVE. I will not ship an unsigned artifact from a laptop. If an assistant wrote the code, it still goes through the same gates.”

## Knowledge check

   Six judgment items. Map each one to a FIRST/BEST stem, not a definition. Check answers, then reset and retry the misses.

       Q1
       A product owner wants a new payout API in this sprint. An engineer opens a ticket to “run DAST on Friday before prod.” What does the security professional do FIRST?

           Approve the DAST window so the sprint is not blocked
           Buy a WAF subscription for the new hostname
           Put security requirements and a threat model on the story before code — abuse cases, object ownership, fail-closed behavior
           Refuse the sprint until the firm reaches CMMI Level 5

       Correct:  c . FIRST on a new feature is 8.1 / A06 work — requirements and design. DAST is a later gate. A WAF is not a design. CMMI Level 5 is not a prerequisite the stem created. Re-read  Mental model  and Side A.

       Q2
       A tester changes  accountId  in a JSON body and reads another customer. The value is a valid UUID. A teammate says “tighten input validation and the WAF.” Why is that the wrong primary fix?

           Because UUIDs cannot be validated
           This is Broken Access Control (A01 / IDOR). The server never checked that the caller owns that object. Validation and a WAF do not create that check
           Because only DAST can fix authorization bugs
           Because parameterized queries would have rejected the UUID

       Correct:  b . The input is well-formed. A01 is authorization, not injection or schema. Code review of the authz path is how you confirm the check exists. Re-read  How to choose .

       Q3
       CI runs SAST and SCA. Pen-testers keep finding runtime auth-bypass and default-credential findings on staging. The lead says “just tune SAST harder.” What is the BEST response?

           SAST does not execute the app, so it structurally cannot see those live flaws. Add DAST and/or IAST against a running build
           Delete SAST — one tool is enough if it is DAST
           Move SCA later so it runs after production traffic exists
           The findings are out of scope because SAST was green

       Correct:  a . Outline 8.2 is a family of tests, not a single scanner. Tuning a static tool cannot create runtime vision. Do not throw away defence-in-depth. Re-read  Decision flow .

       Q4
       A Log4Shell-style CVE drops. You have hours to say which of 200 microservices ship the library, including transitive dependencies. Which control most directly answers that question?

           A WAF rule that blocks the exploit string
           Re-running last year’s pen-test report
           Code signing on the laptop that built the jars
           An SBOM per build, so you can query the component — including transitive ones

       Correct:  d . Impact analysis is a visibility problem. An SBOM is the inventory. A WAF may buy time; it does not tell you where the library lives. Signing proves origin, not contents. Re-read  Runtime path  and Side C.

       Q5
       A fintech lead wants to catch known-vulnerable third-party libraries  before  merge — true shift-left. Which gate at which phase BEST does that?

           DAST against production after the marketing launch
           SCA on the CI build / merge, failing closed on policy-critical CVEs
           Annual STRIDE workshop with no pipeline hook
           Manual code review of every upstream source tarball

       Correct:  b . SCA reads lockfiles and artifacts for known CVEs and can block merge. DAST and pen-tests are later and do not inventory libraries. STRIDE is design, not CVE feed. Reviewers do not scale to transitive jars. Re-read the choose table and Side B.

       Q6
       Checkout applies a coupon twice if the user double-clicks Pay. SAST is clean. DAST returned 200 on the happy path and never tried the race. What is the BEST next control?

           Turn the WAF to block all POST bodies that contain the word “coupon”
           Run SCA — double-spend is a library CVE
           Manual code review (and a misuse-case test) of the payment workflow — this is business logic, which scanners routinely miss
           Declare residual risk accepted because both automated gates were green

       Correct:  c . Code review vs DAST is the point of this lesson. Logic and intent need a human (and a test written for that abuse). A green scanner is not acceptance of a known design hole. Re-read  Decision flow .

       Check answers
       Reset

## Sources

- ISC2 — CISSP Certification Exam Outline (effective 15 April 2024). Domain 8 weight 10%. Objectives 8.1–8.5 are the spine of this lesson. AI-in-Domain-8 note taken from the same outline page. No other exam percentages are claimed.

- OWASP — Top 10:2025 (A01–A10, including A03 Software Supply Chain Failures and A10 Mishandling of Exceptional Conditions).

- OWASP — Software Assurance Maturity Model (SAMM) (prescriptive maturity). Contrast: CMM/CMMI as process maturity (named in 8.1); BSIMM as well-known descriptive benchmark, not an ISC2-named requirement.

- OWASP — Query Parameterization Cheat Sheet (A05 control).

- NIST — SP 800-218, Secure Software Development Framework (SSDF) v1.1 (PO / PS / PW / RV).

- NIST — SP 800-218A , SSDF community profile for generative AI and dual-use foundation models.

- CISA — Software Bill of Materials (SBOM) .

- OpenSSF / community — SLSA (Supply-chain Levels for Software Artifacts) provenance.

 Related:  CISSP overview (all 8 domains)  ·  Domain 7: Security Operations  ·  Domain 6: Assessment and Testing  ·  Domain 8 assessment  ·  8-week roadmap

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt