Integrationsplatformen eller partnerprogrammet kræver en sikkerhedstest

Mange softwarehuse sælger gennem en større platform: en markedsplads for udvidelser, et partnerprogram hos en systemleverandør eller en integrationsplatform, som kunderne bruger til at koble systemer sammen. Før jeres app eller integration bliver godkendt eller fornyet, kan platformen kræve en sikkerhedstest.

Det rigtige svar hviler på at behandle platformen som en kunde med sine egne, skrevne regler. Læs programmets krav til omfang, tester og dokumentation, afgræns testen til jeres egen integration og den webløsning og det API, den bygger på, og planlæg, så godkendelsen ikke bliver en flaskehals for jeres releases.

Platformen er en særlig slags kunde

En platform stiller krav på vegne af alle sine brugere. Den har set mange integrationer og kan have en fast proces med skemaer, frister og en bestemt form for dokumentation. Det gør kravet mere forudsigeligt end en enkelt kundes, men også mindre fleksibelt. Det er ikke altid muligt at forhandle om formen.

Til gengæld er der en fordel: når jeres integration er godkendt, kan det bruges over for de kunder, der henter den gennem platformen. Nogle af dem nøjes derfor med færre spørgsmål. Det gælder dog kun den del af jeres produkt, platformen har set på. → Flere kunder stiller forskellige krav

Læs programmets egne krav

Find programmets dokumentation om sikkerhed og gennemgå den, før I bestiller noget. Den vil måske have svar på nogle af disse spørgsmål:

Omfang · om det er jeres integration, jeres hele webløsning eller kun den del, platformens brugere kommer i kontakt med.
Tester · om testen må udføres af jer selv, af en ekstern part, eller af en tester, platformen har godkendt.
Form · om platformen vil have en rapport, et udfyldt skema eller en erklæring.
Fund · om bestemte typer fund skal være rettet, før godkendelse gives.
Gentagelse · om testen skal gentages ved nye versioner eller med et fast interval.

Hvis dokumentationen er uklar, så spørg platformens partnerkontakt skriftligt. Gem svaret, for programmets regler kan ændre sig fra år til år. Notér også, hvilken version af reglerne jeres godkendelse bygger på. Når platformen opdaterer kravene, kan I så hurtigt se, hvad der er nyt, og om det berører jer før næste fornyelse.

Hvad testen typisk skal dække

Kernen er som regel den forbindelse, jeres løsning har til platformen og til de brugere, der kommer fra den. Det kan handle om, hvordan jeres løsning modtager og opbevarer adgangen til platformens data, hvilke rettigheder jeres integration beder om, og hvordan data fra én kundes platform holdes adskilt fra en andens. En integration, der beder om bredere adgang, end den bruger, kan i sig selv være et punkt, platformen spørger til.

Den webløsning, brugerne møder, når de opsætter integrationen, hører som regel også med. Det gælder login, kontoindstillinger og de sider, hvor kunden giver jeres løsning adgang til sine data.

API’et er ofte det vigtigste testområde, fordi det er her, platformen og jeres løsning udveksler data. OWASP’s API Security-projekt samler de risici, der oftest går igen ved API’er, og kan bruges som fælles reference, når I beskriver omfanget for testeren. → Produktets API i testen

Hvis jeres løsning sender data tilbage til platformen eller til kunderne via udgående kald, hører de med. → Webhooks og udgående integrationer

Platformens egen del er ikke jeres

Platformen har sit eget ansvar for sin egen sikkerhed, og den har normalt regler for, hvad partnere må teste hos den. Jeres test skal holde sig til jeres løsning og jeres integration, ikke til platformen selv. Spørg testeren, hvordan grænsen trækkes i praksis, og få den beskrevet i omfanget. Hvis testen skal bruge en testkonto hos platformen, så undersøg, om programmet stiller sådan en til rådighed for partnere.

Gør grænsen tydelig i rapporten også. Platformens gennemgang og kundernes spørgsmål bliver lettere at besvare, når det står klart, hvad jeres test dækkede, og hvad der hviler på platformens egen kontrol. → Integrationer til kundernes systemer

Godkendelse og releases

Hvis programmet kræver en ny gennemgang ved hver større version, kan godkendelsen begynde at styre jeres releaseplan. Find ud af, hvad programmet regner for en ny version, og om mindre rettelser kan udgives uden en ny gennemgang. Spørg også, om en sikkerhedsrettelse kan udgives hurtigt, hvis der opstår et akut behov, eller om den skal vente på platformens behandling. Svaret har betydning for, hvordan I håndterer et alvorligt fund efter godkendelsen.

Planlæg testen, så den rammer den version, der skal godkendes, og så der er tid til at rette fund før platformens frist. En test af en udgave, der allerede er erstattet, når platformen læser rapporten, skaber ekstra arbejde for begge parter. → Retest efter rettelser i en ny release

Genbrug i forhold til jeres direkte kunder

Den test, platformen kræver, kan ofte også bruges over for jeres direkte kunder, hvis omfanget dækker det, de bruger. Aftal med testeren, at rapporten får et resumé, der kan deles uden at afsløre platformens interne forhold. Omvendt kan en test, I allerede har af hele produktet, måske opfylde platformens krav, hvis platformen accepterer formen og testeren.

Spørg platformen, før I bestiller en ekstra test. Det kan spare et helt forløb og give jer én rapport, der kan bruges flere steder. Har I en udviklerportal eller et offentligt API, som også bruges uden om platformen, bør det med i overvejelserne. → Offentligt API og udviklerportal

Det skal I lade være med

At bestille, før programmets krav er læst · Formen og testeren kan være låst på forhånd.
At teste platformen i stedet for jeres løsning · Platformens egne regler for test skal overholdes.
At teste en version, der ikke er den, der skal godkendes · Rapporten bliver afvist eller forældet.
At gå ud fra, at godkendelsen dækker hele produktet · Den gælder det, platformen så på.
At glemme fornyelsen · Mange programmer kræver en ny gennemgang med tiden.

Hvad kan og ikke kan konkluderes

En test, der følger programmets krav, kan dokumentere over for platformen, at jeres integration er undersøgt efter de aftalte rammer. Den kan også bruges over for kunder, der bruger netop den integration.

Den kan ikke dokumentere platformens egen sikkerhed eller dele af jeres produkt uden for omfanget. Om integrationen bliver godkendt, afgør platformen.

Tjekliste før platformens gennemgang

☐ Er programmets krav til omfang, tester og form læst?
☐ Er uklare punkter afklaret skriftligt med partnerkontakten?
☐ Er grænsen mellem jeres løsning og platformen beskrevet?
☐ Dækker omfanget API’et og udgående kald?
☐ Rammer testen den version, der skal godkendes?
☐ Er der tid til rettelser før platformens frist?
☐ Kan resuméet bruges over for direkte kunder?

Kilder

OWASP API Security: OWASP’s projekt om de mest udbredte sikkerhedsrisici ved API’er, herunder API Security Top 10.
OWASP Web Security Testing Guide: faglig ramme for test af webapplikationer.

Senest gennemgået: oktober 2026.