# Sikkerhetsgjennomgang i Claude Code: trinnvis veiledning og automatisering med GitHub Action i 2026 > Slik sjekker du sikkerheten i et vibe-prosjekt med /security-review i Claude Code. Oppsettstrinn, en GitHub Action-mal, 6 typer sårbarheter og ærlige begrensninger. Source: https://ailoot.ai/blog/nb/claude-code-security-review/ Canonical: https://ailoot.ai/blog/nb/claude-code-security-review/ Language: nb Publisher: Ailoot (https://ailoot.ai/) Translation: guide-212 Revision: sha256-1e4369529c5ee66e5567373f986645949311dc362c0e8f897ae17a6240c49cf6 Forfatteren av originalmaterialet beskriver sin erfaring: «Jeg kjørte nettopp security-review på mitt eget vibe-prosjekt, og teamet fant flere reelle problemer på 4 minutter som allerede er rettet.» Dette er det samme arbeidet som tidligere tok en ekstern konsulent en dag. Mer materiale om konfigurering av verktøy finnes i [Ailoot-dokumentasjonen](https://ailoot.ai/docs/).
[Ailoot-veiledninger](https://ailoot.ai/docs/)
## Hva er /security-review i Claude Code?
Høydepunkter `/security-review` er en innebygd Claude Code-kommando som kjører en sikkerhetsanalyse av hele prosjektet eller de gjeldende endringene direkte fra terminalen. Anthropic lanserte den 20. februar 2026 som en del av Claude Code Security og gjorde den tilgjengelig for alle Pro-, Max- og API Console-brukere. Forespørselen betales fra den vanlige Claude API-saldoen din.
Kommandoen fungerer i to moduser. Lokalt: kjør `/security-review` i terminalen, så leser Claude repositoriet og lager en rapport. På serversiden: den samme motoren installeres som en GitHub Action og legger automatisk inn kommentarer direkte i hver Pull Request. I motsetning til klassiske SAST-skannere (Snyk Code, Semgrep, SonarQube) fungerer ikke `/security-review` ut fra faste regler. Den leser kode som en erfaren utvikler: følger dataflyten, forstår hvilket rammeverk du bruker og hvor tillitsgrensene går, og oppdager sårbarheter som ikke er beskrevet av en regel.

Claude Code Security leser og analyserer koden din slik en menneskelig sikkerhetsforsker ville gjort: den forstår hvordan komponentene samhandler, følger hvordan data beveger seg gjennom applikasjonen og oppdager komplekse sårbarheter som regelbaserte verktøy overser.

— Anthropic, https://www.anthropic.com/news/claude-code-security
Det betyr ikke at `/security-review` erstatter en ekstern penetrasjonstest eller live-testing i et stagingmiljø. Den kan automatisere deler av den innledende kodegjennomgangen, men artikkelen måler ingen andel av revisjonsdekningen. Nedenfor forklarer jeg hvordan du kjører den riktig, og hva Claude vil finne i prosjektet ditt. ## Hvordan kjører du /security-review i 5 trinn?
Høydepunkter Oppdater Claude Code til den nyeste versjonen, åpne prosjektet i en terminal, kjør `/security-review`, vent på rapporten (1 til 5 minutter for et gjennomsnittlig prosjekt), les alvorlighetsvurderingene og be Claude om å bruke rettelsene. Kommandoen fungerer med alle teknologistakker: Next.js, Django, FastAPI, Rails, Go, Rust. Ingen spesiell konfigurasjon kreves.
**Trinn 1. Oppdater Claude Code.** Kommandoen fungerer fra og med utgivelsen datert 20. februar 2026. ```bash claude update ``` Hvis du installerte Claude Code via npm, kan du også gjøre dette: ```bash npm install -g @anthropic-ai/claude-code@latest ``` Kontroller at `/security-review` har dukket opp: ```bash claude /help | grep security ``` **Trinn 2. Åpne prosjektet og logg inn i Claude Code.** ```bash cd ~/projects/my-vibe-project claude ``` **Trinn 3. Kjør kommandoen.** Skriv ganske enkelt inn dette i Claude Code: ``` /security-review ``` Claude går automatisk gjennom 3 analysefaser: 1. **Undersøkelse av repository-kontekst** - leser strukturen og identifiserer teknologistakken, rutene og databasespørringene. 2. **Sammenlignende analyse** - sammenligner den gjeldende tilstanden med typiske sårbarhetsmønstre for denne teknologistakken. 3. **Vurdering av sårbarheter** - lister opp hver mistanke med et konfidensnivå på en skala fra 1-10. Bare funn med konfidens ≥ 8 tas med i rapporten. **Trinn 4. Les rapporten.** Utdataene er en Markdown-tabell. For hvert problem oppgir Claude: - **Fil og linjenummer** (for eksempel `src/auth/login.ts:42`) - **Alvorlighetsgrad** (HIGH / MEDIUM / LOW) - **Kategori** (`sql_injection`, `xss`, `auth_bypass`, `insecure_storage`) - **Beskrivelse** - hva som er galt - **Utnyttelsesscenario** - hvordan en angriper kan utnytte det - **Anbefaling** - hvordan det kan løses **Trinn 5. Be om at rettelsene brukes.** Deretter kan du jobbe med den som med en vanlig agent: > «Bruk rettelsene med alvorlighetsgrad HIGH fra rapporten, én om gangen, med en PR-beskrivelse.» Claude åpner hver fil og foreslår en endring; du bekrefter den. I et reelt prosjekt lukket jeg 5 funn på 40 minutter i stedet for de planlagte 3 timene.
[Ailoot-veiledninger](https://ailoot.ai/docs/)
## Hvilke sårbarheter finner /security-review?
Høydepunkter Claude oppdager 6 kategorier: SQL-injeksjon og injeksjoner generelt, XSS, problemer med autentisering og autorisasjon, lekkasjer av sensitive data, sårbarheter i tredjepartsavhengigheter og hardkodede hemmeligheter i kode. Kommandoen kan også håndtere autentiseringslogikk som er spredt over flere filer, noe regelbaserte skannere ikke kan gjøre.
Den fullstendige listen over hva som inngår i analysen som standard, er beskrevet i [Anthropics offisielle dokumentasjon](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code): | Kategori | Hva den ser etter | |----|----| | **SQL-injeksjon** | Direkte sammenkjeding av strenger i SQL, usikre ORM-kall (`raw()` uten parametere), Prisma `$queryRawUnsafe` | | **XSS** | Gjengivelse med `dangerouslySetInnerHTML` uten rensing, malsystemer uten automatisk escaping, `innerHTML` fra brukerinndata | | **Autentiseringsfeil** | Gjenbrukbare tokener, manglende tillatelseskontroller i API-ruter, JWT uten utløpsdato, sesjonsfiksering | | **Usikker datahåndtering** | Validering bare på klientsiden, svar med ekstra felt (over-fetching), åpen videresending | | **Sårbarheter i avhengigheter** | Sårbare versjoner av npm/pip/cargo-pakker, kontrollert med `npm audit` og tilsvarende verktøy | | **Hemmeligheter** | Hardkodede API-nøkler, tokener i `.env.example`, passord i kode | I tillegg dekker kommandoen kategorier som automatiserte skannere sjelden dekker: - **Kommandoinjeksjon** - kjøring av brukerinndata i et shell (`child_process.exec(userInput)`) - **Stikryssing** - lasting av en fil via `../../etc/passwd` - **XXE** - XML med eksterne entiteter - **Malinjeksjon** - SSTI i Jinja/Handlebars/EJS - **NoSQL-injeksjon** - `$ne`- og `$gt`-operatorer i MongoDB-spørringer - **Feil bruk av kryptografi** - bruk av MD5, ECB-modus eller en statisk IV Claude gir hvert funn en alvorlighetsgrad. Skalaen er enkel: - **HIGH** - fjernutnyttelse uten autentisering, datalekkasje som påvirker alle brukere - **MEDIUM** - utnyttelse med tilleggsvilkår (en sesjon kreves / spesifikke inndata) - **LOW** - en mulig angrepsvektor, ikke kritisk nå, men verdt å rette Nyttig å vite: I standardkonfigurasjonen **rapporterer ikke** Claude DoS, hastighetsbegrensning, minneuttømming, åpne videresendinger uten påvist effekt, regex-injeksjon / ReDoS eller forfalskning av logger. Dette er tilsiktet, slik at du ikke oversvømmes av støy. Hvis disse kategoriene er viktige, kan du utvide reglene (se avsnittet om filtrering av falske positiver nedenfor). ## Hvordan setter du opp en GitHub Action for automatisk gjennomgang?
Høydepunkter Anthropic har lansert den offisielle actionen `anthropics/claude-code-security-review@main`. Den kobles til med én workflow-fil og kommenterer automatisk direkte i hver Pull Request om sårbarhetene den finner. Konfigurer `CLAUDE_API_KEY` og arbeidsflytens tillatelser. Den offisielle Actionen advarer om at den ikke er herdet mot promptinjeksjon og bør gjennomgå betrodde PR-er. Undersøk bidragsyter- og arbeidsflyttilgang før aktivering.
**Trinn 1. Skaff en API-nøkkel.** Gå til [console.anthropic.com](https://console.anthropic.com/), opprett en API-nøkkel og kopier den. **Trinn 2. Legg nøkkelen i repository-hemmelighetene.** I GitHub: Settings → Secrets and variables → Actions → New repository secret. Gi den navnet `CLAUDE_API_KEY`; verdien er nøkkelen din. **Trinn 3. Opprett en workflow-fil.** Lagre den som `.github/workflows/security.yml`: ```yaml name: Security Review permissions: pull-requests: write contents: read on: pull_request: jobs: security: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha || github.sha }} fetch-depth: 2 - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} ``` **Trinn 4. Slå sammen branchen med main.** Actionen starter automatisk ved neste PR. **Dette gjør actionen:** - Kjører på hver åpen eller synkronisert Pull Request. - Henter diffen mellom PR-branchen og main. - Kjører samme motor som lokal `/security-review`. - Legger inn kommentarer direkte på kodelinjene der det finnes mistanker. - Kopierer hele rapporten til Job Summary. **Viktige detaljer i `permissions`:** - `pull-requests: write` - for å legge inn kommentarer direkte i koden. - `contents: read` - for å lese kode. Ingen `write`. Actionen endrer ikke koden selv; den rapporterer bare. Dette tillatelsessettet er tilstrekkelig for et privat repository. For et offentlig repository kan du også angi `actions: read` hvis du bruker gjenbrukbare workflows. ## Hvordan filtrerer du falske positiver og endrer følsomheten?
Høydepunkter Actionen har 9 inndata du kan bruke til å konfigurere oppførselen for prosjektet ditt. De viktigste er: `exclude-directories` (for eksempel `tests/,fixtures/`), `false-positive-filtering-instructions` (bane til en md-fil med reglene dine om «dette er ikke en sårbarhet fordi...») og `custom-security-scan-instructions` for ekstra domenespesifikke kontroller.
Fullstendig tabell over inndata for GitHub Action ([kilde: repository-README](https://github.com/anthropics/claude-code-security-review)): | Inndata | Standard | Hva den gjør | |----|----|----| | `claude-api-key` | \- | Anthropic API-nøkkel. Påkrevd. | | `comment-pr` | `true` | Om kommentarer skal legges inn direkte i PR-en | | `upload-results` | `true` | Om resultatet skal lagres som et artefakt i 90 dager | | `exclude-directories` | \- | Kommaseparert: `tests/,docs/,fixtures/` | | `claude-model` | `claude-opus-4-1-20250805` | Hvilken modell som skal brukes | | `claudecode-timeout` | `20` | Tidsavbrudd i minutter | | `run-every-commit` | `false` | Kjør ved hver push, ikke bare ved PR-er | | `false-positive-filtering-instructions` | \- | Bane til en md-fil med reglene dine | | `custom-security-scan-instructions` | \- | Bane til en md-fil med tilleggskontroller | **Eksempel på konfigurering av filtrering av falske positiver.** Opprett filen `.claude/security/false-positives.md`: ```markdown # Regler for filtrering av falske positiver i prosjektet vårt - All `dangerouslySetInnerHTML` i `src/lib/email/layout.ts` er trygg - HTML-en settes sammen fra betrodde maler og går gjennom `sanitize-html` når den skrives til databasen, ikke når den gjengis. - Ikke rapporter hardkodede test-API-nøkler i `__tests__/fixtures/*.ts`. Alle nøklene begynner med `sk-test-fake-`. - Sammenkjeding av SQL i `src/lib/admin/migrations.ts` er akseptabel - filen kjøres bare som root, og inndataene kommer fra miljøvariabler. ``` Koble den til i workflowen: ```yaml - uses: anthropics/claude-code-security-review@main with: comment-pr: true claude-api-key: ${{ secrets.CLAUDE_API_KEY }} false-positive-filtering-instructions: .claude/security/false-positives.md ``` **Tilpassede instruksjoner for sikkerhetsskanning** er tilsvarende. Opprett en fil med regler som er spesielt viktige for prosjektet ditt: ```markdown # Ekstra kontroller for prosjektet vårt - Alle endepunkter under `/api/admin/*` må kontrollere administratorrollen gjennom en delt wrapper. Uten denne wrapperen er alvorlighetsgraden HIGH. - Alle YooKassa / CloudPayments-webhooks må kontrollere signaturen før brødteksten analyseres. Uten dette er alvorlighetsgraden HIGH. - Magic-link-tokener må bare kunne brukes én gang (markeres som brukt etter den første gyldige forespørselen). Gjenbrukbare tokener har alvorlighetsgrad MEDIUM. ``` Dette er ikke lenger en Anthropic-forhåndsinnstilling: Du overfører ekspertisen din om prosjektet til regler som Claude bruker hver gang. Det er essensen av «metodikk over modell». Hvis du vil vite mer om kontekstmetodikk for Claude, kan du lese veiledningene [«Slik konfigurerer du CLAUDE.md»](https://ailoot.ai/blog/nb/claude-md-template/) og [«Second Brain i Claude Code»](https://ailoot.ai/blog/nb/claude-code-second-brain/). ## Hva oppdager Claude IKKE, og hvorfor: ærlige begrensninger?
Høydepunkter En kodegjennomgang alene prøver ikke den kjørende applikasjonen eller verifiserer det utrullede miljøet. Den kan flagge mulige kappløpsforhold, forretningslogikkfeil eller konfigurasjonsproblemer i koden, men stagingtester og inspeksjon av faktisk utrulling trengs for å bekrefte atferd og gjenstående risiko.
Anthropic lister tydelig opp hva som er deaktivert som standard, og hvorfor ([kilde: repository-README](https://github.com/anthropics/claude-code-security-review)): - **Tjenestenektangrep (DoS)** - for mye støy, nesten alltid liten påvirkning. - **Bekymringer rundt hastighetsbegrensning** - håndteres på infrastrukturnivå, ikke i kode. - **Uttømming av minne / CPU** - det samme. - **Generell validering av inndata uten påvist effekt** - validering av hvert felt skaper et skred av falske positiver. - **Åpen videresending** - ofte tilsiktet oppførsel. Dette kan kodegjennomgang alene ikke fullt ut verifisere uten kjøretids- eller utrullingsbelegg: - **Konfigurasjon av produksjonsserveren.** NGINX-headere, CORS-policyer, TLS-innstillinger, lytteporter. Disse må kontrolleres manuelt i et stagingmiljø. - **Kappløpsforhold.** For eksempel dobbeltforbruk ved samtidige refusjonsforespørsler. Statisk analyse kan flagge mistenkelige mønstre, men samtidig atferd må fortsatt testes. - **Feil i betalingsforretningslogikk.** Hvis ordrebeløpet beregnes på klientsiden og bare sendes videre til betalingsleverandøren, er det alvorlighetsgrad HIGH, men Claude oppdager ikke alltid dette mønsteret uten eksplisitt kontekst om hvordan betalingen skal fungere. - **IDOR på databasenivå.** Hvis spørringen `SELECT * FROM orders WHERE id = $1` ikke kontrollerer `WHERE user_id = $session.userId`, oppdager Claude det ofte. Men hvis kontrollen er implementert gjennom ORM-mellomvare og Claude ikke kan se hele dataflyten, kan den overse det. - **Motstandsdyktighet mot sosial manipulering / phishing.** Dette har ingenting med kode å gjøre. Bruk `/security-review` som innledende statisk gjennomgang. Følg opp med dynamiske tester i staging, rolle- og tillatelseskontroller, relevante SAST-kontroller og gjennomgang av faktisk utrullet konfigurasjon. Ingen målt dekningsprosent fastslås her. Avgjør omfang og tidspunkt for ekstern vurdering ut fra systemets risikoer og endringer. Verken én kommando eller periodisk ekstern revisjon fastslår 100 % sikkerhetsdekning. ## Hvordan forfatteren av originalmaterialet gjennomførte en sikkerhetsgjennomgang av et vibe-prosjekt
Høydepunkter Jeg kjørte `/security-review` på mitt eget TypeScript-prosjekt med Next.js, Prisma, PostgreSQL og Redis. På 4 minutter gjennomførte kommandoen en innledende revisjon, returnerte flere godt underbygde funn med ulik alvorlighetsgrad, og til slutt fullførte jeg fungerende rettelser på halvannen time. Dette var billigere og raskere enn enhver ekstern penetrasjonstest.
Hva dukket opp? Et typisk bilde av et gjennomsnittlig vibe-prosjekt på stadiet «fungerer i produksjon, men er ikke gjennomgått»: flere mistanker om autentiseringsflyten, logikken for behandling av webhooks fra betalingsintegrasjonen, filopplasting og et par konkrete merknader om HTML-håndtering ved gjengivelse. Jeg beskriver ikke detaljene offentlig; noen anbefalinger er allerede fulgt, mens andre fortsatt ligger i en PR. I det rapporterte prosjektet var den innledende skanningen nyttig og rask. Det fastslår ingen revisjonsdekningsprosent eller generell fullføringstid. Dette avviste jeg som falske positiver: - Funn om DoS via regexer i validering av inndata - den faktiske belastningen treffer ikke disse regexene. - Ett funn om en hardkodet API-nøkkel - det var en testnøkkel med et tydelig `fake-`-prefiks i fixtures. Hvor lang tid tok det? Selve kjøringen tok 4 minutter. Det tok 25 minutter å gå gjennom rapporten. Det tok omtrent en time å bruke rettelsene og kjøre testene. Totalt: omtrent halvannen time fra «startet» til «alt i main». En ekstern penetrasjonstest av samme område tar en kalenderuke og koster flere titalls ganger mer. Viktigste poeng. `/security-review` erstatter ikke en ekstern penetrasjonstest. Den kan identifisere nyttige kodefunn, slik den gjorde i forfatterens rapporterte fireminutters skanning. Gjennomgå og test rettelsene, og kontroller deretter kjøretidsatferd og utrullet konfigurasjon separat. Skanningen fjerner ikke prosjektets sikkerhetsrisiko. ## Hvordan integrerer du /security-review i pre-commit-rutinen?
Høydepunkter Før du committer vesentlige endringer, kjører du `/security-review` i prosjektøkten, leser funnene, retter bekreftede problemer og kjører relevante tester på nytt. Dette er en gjennomgangsprosedyre, ikke et teknisk forbud mot commit.
Den tidligere viste hooken med `git_commit`, `--severity HIGH` og `--fail-on-find` er ingen dokumentert fungerende oppskrift og må ikke brukes som sikkerhetsport. Artikkelen gir ingen verifisert lokal hook som blokkerer commits. Den offisielle GitHub Actionen ovenfor gir automatiserte PR-funn. Ikke utled at den blokkerer commits eller sammenslåing bare fordi den kommenterer en PR. En fullstendig forklaring av hooks finnes i veiledningen [«Hooks i Claude Code»](https://ailoot.ai/blog/nb/claude-code-hooks/). Et alternativ med [rutiner](https://ailoot.ai/blog/nb/claude-code-routines/) er å opprette en `pre-deploy-check`-rutine som kjører `/security-review` + `npm run build` + `npm run test` med én kommando. Mer materiale finnes i Ailoot-dokumentasjonen. Hvis du bruker [MCP-servere](https://ailoot.ai/blog/nb/mcp-servers-claude-code/), kan du integrere funn fra `/security-review` med et hendelsessystem (Sentry, Linear, Notion), slik at hvert funn med alvorlighetsgrad HIGH automatisk blir en sak. ## Vanlige spørsmål om /security-review
Høydepunkter 5 vanlige spørsmål: hva det koster, hvor ofte du bør kjøre det, hvilke teknologistakker det fungerer med, hva du skal gjøre hvis Claude allerede har funnet denne sårbarheten, og om du kan kjøre det bare på bestemte filer. Korte svar, uten unødvendig prat.
**Hva koster én kjøring?** Det avhenger av prosjektstørrelsen. På mine 30K linjer bruker én kjøring omtrent \$0.30-0.50 av API-saldoen. Et stort bedriftsrepository med en million linjer koster opptil \$5-8 per kjøring. Det er flere titalls ganger billigere enn et abonnement på en SaaS-skanner. **Hvor ofte bør jeg kjøre det lokalt?** Minst før hver produksjonsutgivelse. Vurder den også før vesentlige commits og PR-er. Artikkelen gir ingen verifisert hook som automatisk blokkerer commits. **Hvilke teknologistakker fungerer det med?** Alle som Claude kan lese. Ifølge forfatterens observasjoner er disse kontrollert: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. Kvaliteten er lavere for svært eksotiske språk (Erlang, Elixir, Clojure), men den finner noe. **Hva skal jeg gjøre hvis Claude finner den samme «sårbarheten» hver gang, selv om den egentlig ikke er en sårbarhet?** Legg den til i `false-positive-filtering-instructions` med en forklaring på «hvorfor dette er trygt». Claude vil slutte å rapportere den i senere kjøringer. **Kan jeg kjøre det bare på bestemte filer?** Lokalt, ja: kjør ganske enkelt `/security-review src/lib/auth/*.ts`. I GitHub Action kontrolleres bare diffen for den gjeldende PR-en, noe som vanligvis er det som menes med «bestemte filer». ## Kilder
### Kilder - [Anthropic - Kunngjøring om lanseringen av Claude Code Security](https://www.anthropic.com/news/claude-code-security) - offisiell kunngjøring datert 20. februar 2026 - [Anthropic Help Center - Automatiserte sikkerhetsgjennomganger i Claude Code](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) - offisielle instruksjoner for bruk - [GitHub: anthropics/claude-code-security-review](https://github.com/anthropics/claude-code-security-review) - kilde til GitHub Action med fullstendig README - [Claude Code Docs - Code Review](https://code.claude.com/docs/en/code-review) - generell Anthropic-dokumentasjon - [Anthropic Help Center - Bruk Claude Security](https://support.claude.com/en/articles/14661296-use-claude-security) - relaterte produkter - [Port - Importer Claude Code Security Reviews](https://docs.port.io/guides/all/ingest-claude-code-security-reviews/) - integrering av resultater i en Internal Developer Portal - [Claude Code Changelog](https://code.claude.com/docs/en/changelog) - historikk over kommandoutgivelser
Mer materiale finnes i [Ailoot-dokumentasjonen](https://ailoot.ai/docs/).
[Ailoot-veiledninger](https://ailoot.ai/docs/)
[Gå til Ailoot](https://ailoot.ai/)
## Spørsmål om denne veiledningen: Sikkerhetsgjennomgang i Claude Code: trinnvis veiledning og automatisering med GitHub Action i 2026 ### Beviser en sikkerhetsrapport uten funn at applikasjonen er sikker? Nei. Den er en innledende kodegjennomgang med mulige falske negativer og filtrering. Verifiser rettelser, prøv rolle- og samtidighetsatferd i staging og undersøk faktisk utrullet konfigurasjon. ### Blokkerer GitHub Actionen automatisk commits eller sammenslåing? Den viste arbeidsflyten etablerer ingen slik garanti. Den publiserer PR-funn. Gjennomgå dem og test bekreftede rettelser. Artikkelen gir ingen verifisert lokal hook som blokkerer commits. ## Ailoot · Selskapet og dets prosjektportefølje Ailoot bygger på etablert driftserfaring, en stor kundebase, stabil tjeneste og løpende KPI-kontroll. Selskapet og dets prosjektportefølje: millioner av kunder; månedlig salg for milliarder. Ailoot bruker denne driftserfaringen til API-tilgang til AI-funksjoner i kundenes produkter, agenter, applikasjoner og automatiseringer.