GitHub Copilot veilig gebruiken: 7 fouten die organisaties maken

cn deze instellingen beheren voor Copilot Business en Enterprise.

1. Je laat secrets in broncode staan omdat Copilot ze toch niet mag gebruiken
   Een API-key, wachtwoord of token hoort niet veilig te worden omdat je het voor Copilot uitsluit. Secrets horen in een passende secret-managementoplossing en moeten uit broncode en versiegeschiedenis worden gehouden. Content exclusion verkleint Copilot-context, maar vervangt geen normaal secretsbeheer.
2. Je verwart bescherming tegen publieke code met een securitycontrole
   GitHub Copilot kan suggesties controleren op overeenkomsten met publiek beschikbare code. Afhankelijk van het beleid worden zulke suggesties geblokkeerd of van een verwijzing voorzien. Dat zegt niets over de vraag of gegenereerde code veilig, logisch correct of geschikt voor jouw applicatie is.
3. Je merge’t Copilot-code zonder menselijke controle
   GitHub benadrukt zelf dat gegenereerde code fouten of beveiligingsproblemen kan bevatten. Behandel Copilot-output daarom als voorgestelde code: voer tests uit, gebruik bestaande code-reviewprocessen en controleer beveiligingskritische wijzigingen extra zorgvuldig voordat je ze accepteert.
4. Je behandelt ieder Copilot-abonnement hetzelfde
   De manier waarop data wordt behandeld hangt mede af van het abonnement en de instellingen. GitHub geeft aan dat gegevens van Copilot Business- en Enterprise-klanten niet worden gebruikt om AI-modellen te trainen. Bij individuele abonnementen kan interactiedata voor modelverbetering worden gebruikt, afhankelijk van de instellingen.

Wil je deze onderwerpen niet alleen als beheerinstellingen kennen, maar ook begrijpen hoe ze samenhangen met verantwoord Copilot-gebruik? In de GitHub Copilot (GH-300) training behandel je onder meer de werking van Copilot, context, gegevensverwerking en verantwoord gebruik.

Welke code je uitsluit, hangt af van je organisatie, maar gevoelige bedrijfslogica, vertrouwelijke configuratie en data met een verhoogd privacy- of beveiligingsrisico verdienen extra aandacht. De eerste vraag is daarbij niet alleen “mag Copilot dit zien?”, maar vooral “hoort deze informatie überhaupt in deze repository te staan?”

Een praktisch startpunt bestaat uit deze categorieën:

1. Vertrouwelijke bedrijfslogica
   Denk aan eigen algoritmes, interne detectieregels of andere code waarvan ongewenste verspreiding grote gevolgen kan hebben.
2. Beveiligingsgevoelige configuratie
   Configuratie rond authenticatie, autorisatie en beveiligingsarchitectuur kan waardevolle informatie over je omgeving bevatten.
3. Testdata met persoonsgegevens of bedrijfsgegevens
   Gebruik waar mogelijk synthetische testdata. Productiedata kopiëren naar ontwikkelomgevingen creëert risico’s die veel verder gaan dan alleen Copilot.
4. Interne documentatie in dezelfde repository
   Repositories bevatten soms architectuurnotities, incidentinformatie of interne instructies naast de broncode. Neem zulke bestanden mee wanneer je bepaalt welke context Copilot mag gebruiken.
5. Secrets en tokens
   Sluit deze niet alleen uit: verwijder ze uit de repository en beheer ze via daarvoor bedoelde voorzieningen. Een exclusion-regel is geen alternatief voor goed secret management.

Content exclusion is daarmee vooral geschikt voor informatie die legitiem in een repository staat, maar die je bewust niet als Copilot-context wilt laten gebruiken.

Voor organisaties met Copilot Business en Enterprise kunnen exclusion-regels op repository-, organisatie- en enterpriseniveau worden ingesteld. GitHub gebruikt die regels onder meer om te voorkomen dat uitgesloten bestanden context leveren aan ondersteunde Copilot-functies.

Begin met het inventariseren van repositories en bestandspaden met een verhoogd risico. Leg daarna vast wie exclusion-regels mag wijzigen en test of ze op de gebruikte ontwikkelomgevingen het verwachte effect hebben. Controleer bovendien afzonderlijk welke agent- en chatfuncties je organisatie toestaat.

Belangrijk: content exclusions bepalen welke context Copilot mag gebruiken, maar vervangen geen toegangsbeheer, secret scanning, code scanning of menselijke code review.

Voor organisaties die juist die bredere beveiligingslaag binnen GitHub willen uitwerken, sluit GitHub Advanced Security (GH-500) daarop aan. Daarin staan onder meer secret scanning, code scanning met CodeQL en beveiligingsbeleid centraal.

Privacy, content exclusions en safeguards vormen in de actuele GH-300-studiegids 10–15% van de gemeten vaardigheden. Het onderwerp gaat dus verder dan weten waar een instelling staat: je moet begrijpen hoe gegevens en context worden behandeld, welke uitsluitingen en beveiligingen beschikbaar zijn en waar de beperkingen zitten.

Dat maakt praktijkkennis belangrijk. Een examenvraag kan juist draaien om het verschil tussen een beschikbare safeguard en wat die safeguard daadwerkelijk afdekt.

De training GitHub Copilot (GH-300) is daarom vooral relevant wanneer je Copilot professioneel inzet én de achterliggende keuzes wilt begrijpen. Startel heeft ruim 25 jaar ervaring met IT-opleidingen; binnen deze training ligt de nadruk niet alleen op codevoorstellen en prompts, maar ook op verantwoord gebruik van Copilot.

Nee. Content exclusion is een nuttige controle voor gevoelige context, maar veilig gebruik vraagt ook om goed repositorybeheer, passende Copilot-policies, secretsbeheer, testen en menselijke code-review.

Controleer bovendien opnieuw je beleid wanneer GitHub nieuwe Copilot-surfaces of agentfuncties toevoegt. Juist omdat de mogelijkheden van Copilot veranderen, moet je beveiligingsbeleid beschrijven wat gebruikers wél mogen doen in plaats van alleen een eenmalige lijst met uitgesloten bestanden vast te leggen.

Wil je die keuzes gestructureerd leren maken, dan vormt de GitHub Copilot (GH-300) training een logische route van dagelijks Copilot-gebruik naar verantwoord en controleerbaar gebruik.