Een beveiligde GitHub-opslagplaats onderhouden

Hier bespreken we enkele van de essentiële beveiligingshulpprogramma's en technieken die beschikbaar zijn voor beheerders van GitHub-opslagplaatsen.

Het belang van een veilige ontwikkelingsstrategie

Toepassingsbeveiliging is belangrijk. Nieuwsservices bevatten regelmatig verhalen over een schending van de systemen van een bedrijf en privébedrijfs- en klantgegevens die zijn gestolen.

Wat zijn de problemen waarmee u rekening moet houden bij het plannen van een veilige ontwikkelingsstrategie? Het is duidelijk dat we gegevens moeten beschermen tegen openbaarmaking aan mensen die er geen toegang toe mogen hebben, maar belangrijker nog, we moeten ervoor zorgen dat informatie alleen wordt gewijzigd of vernietigd wanneer deze geschikt is.

We moeten ervoor zorgen dat we op de juiste manier verifiëren wie toegang heeft tot de gegevens en of ze over de juiste machtigingen beschikken om dit te doen. Via historische of archiveringsgegevens of logboeken moeten we bewijs kunnen vinden wanneer er iets mis is.

Er zijn veel aspecten voor het bouwen en implementeren van beveiligde toepassingen. Hier volgen drie aandachtspunten:

• Er is een algemeen kennisprobleem: veel ontwikkelaars en andere personeelsleden gaan ervan uit dat ze de beveiliging begrijpen, maar dat niet. Cybersecurity is een voortdurend veranderende discipline. Een programma van doorlopend onderwijs en training is essentieel.

• Code moet correct en veilig worden geschreven: We moeten ervoor zorgen dat de code correct is geschreven en de vereiste functies veilig implementeert. We moeten er ook voor zorgen dat de functies zijn ontworpen met het oog op beveiliging.

• Toepassingen moeten voldoen aan regels en voorschriften: we moeten ervoor zorgen dat de code voldoet aan de vereiste regels en voorschriften. We moeten testen op naleving tijdens het bouwen van de code en vervolgens periodiek opnieuw testen, zelfs na de implementatie.

Beveiliging bij elke stap

Beveiliging is niet iets wat u later aan een toepassing of een systeem kunt toevoegen. Veilige ontwikkeling moet deel uitmaken van elke fase van de levenscyclus van softwareontwikkeling. Dit concept is nog belangrijker voor kritieke toepassingen en toepassingen die gevoelige of zeer vertrouwelijke informatie verwerken.

Om teams in de praktijk verantwoordelijk te houden voor wat ze ontwikkelen, moeten processen overschakelen of eerder in de ontwikkelingslevenscyclus worden voltooid. Door stappen van een laatste fase tijdens de implementatie naar een eerder stadium in het proces te verplaatsen, worden er minder fouten gemaakt en kunnen ontwikkelaars sneller werken.

Concepten voor toepassingsbeveiliging waren in het verleden geen focus voor ontwikkelaars. Afgezien van de onderwijs- en trainingsproblemen, is het omdat hun organisaties de nadruk leggen op een snelle ontwikkeling van functies.

Met de introductie van DevOps-procedures is het testen van beveiliging echter eenvoudiger te integreren in de pijplijn. In plaats van een taak te zijn die door beveiligingsspecialisten wordt uitgevoerd, moeten beveiligingstests alleen deel uitmaken van de dagelijkse leveringsprocessen.

Over het algemeen kan het toevoegen van beveiliging aan uw DevOps-procedures eerder in de ontwikkelingslevenscyclus, wanneer rekening wordt gehouden met de tijd voor opnieuw werk, ontwikkelteams eerder problemen ondervangen. Het detecteren van problemen eerder kan de totale tijd die het kost om kwaliteitssoftware te ontwikkelen, verminderen.

Naar links schuiven is een proceswijziging, maar het is geen enkel besturingselement of specifiek hulpmiddel. Het gaat erom om al uw beveiliging meer op ontwikkelaars gericht te maken en ontwikkelaars beveiligingsfeedback te geven waar ze zich bevinden.

Functies van het beveiligingstabblad

GitHub biedt beveiligingsfuncties waarmee u gegevens veilig kunt houden in opslagplaatsen en in alle organisaties. Ga als volgende te werk om het tabblad Beveiliging te vinden:

1. Ga op GitHub.com naar de hoofdpagina van de opslagplaats.

2. Onder de naam van de opslagplaats selecteer je Beveiliging.

Op het tabblad Beveiliging kunt u functies toevoegen aan uw GitHub-werkstroom om beveiligingsproblemen in uw opslagplaats en codebasis te voorkomen. Deze functies zijn onder andere:

• beveiligingsbeleid waarmee u kunt opgeven hoe u een beveiligingsprobleem in uw project kunt rapporteren door een SECURITY.md bestand toe te voegen aan uw opslagplaats.
• Dependabot-waarschuwingen die u waarschuwen wanneer GitHub detecteert dat uw opslagplaats gebruikmaakt van een kwetsbare afhankelijkheid of malware.
• Beveiligingsadviezen die u kunt gebruiken om privé informatie over beveiligingsproblemen in uw opslagplaats te bespreken, op te lossen en te publiceren.
• codescans waarmee u beveiligingsproblemen en fouten in uw code kunt vinden, ordenen en oplossen.
• Geheim scannen waarmee tokens, referenties en geheimen worden gedetecteerd die zijn vastgelegd in uw opslagplaats en die kunnen worden geblokkeerd voordat de push wordt uitgevoerd. Pushbeveiliging is standaard ingeschakeld voor openbare opslagplaatsen.

Zie GitHub-beveiligingsfunctiesvoor meer informatie.

Vervolgens verkennen we enkele van deze functies en leren we manieren om beveiligings- en operationele verantwoordelijkheden te verdelen over alle fasen van de levenscyclus van softwareontwikkeling.

Een beveiligingsbeleid communiceren met SECURITY.md

De communityvoordelen van GitHub zijn aanzienlijk, maar ze dragen ook potentiële risico's met zich mee. Het feit dat iedereen publiekelijk bugfixes kan voorstellen, brengt bepaalde verantwoordelijkheden met zich mee. Het belangrijkste is de verantwoordelijke openbaarmaking van informatie die kan leiden tot beveiligingsexplots voordat hun onderliggende bugs kunnen worden opgelost. Ontwikkelaars die beveiligingsproblemen willen melden of oplossen, zoeken naar een SECURITY.md-bestand in de hoofdmap van een opslagplaats om hun zorgen op verantwoorde wijze bekend te maken. Het bieden van richtlijnen in dit bestand versnelt uiteindelijk de oplossing van deze kritieke problemen.

Zie SECURITY.mdvoor meer informatie over .

GitHub-beveiligingsadviezen

Met GitHub-beveiligingsadviezen kunnen onderhouders van opslagplaatsen privé een beveiligingsprobleem in een project bespreken en oplossen. Nadat onderhouders van opslagplaatsen hebben samengewerkt aan een oplossing, kunnen ze het beveiligingsadvies publiceren om het beveiligingsprobleem openbaar te maken in de community van het project. Door beveiligingsadviezen te publiceren, maken opslagplaatsonderhouders het voor hun community gemakkelijker om pakketafhankelijkheden bij te werken en de gevolgen van de beveiligingsproblemen te onderzoeken. GitHub slaat de gepubliceerde adviezen op in de lijst Common Vulnerabilities and Exposures (CVE). Deze lijst wordt gebruikt voor het automatisch melden van betrokken opslagplaatsen die gebruikmaken van software met een vermeld beveiligingsprobleem. Zie Over beveiligingsadviezen voor opslagplaatsenvoor meer informatie.

Gevoelige bestanden uit uw opslagplaats houden met .gitignore

Ontwikkelaars kunnen eenvoudig bestanden in een doorvoer over het hoofd zien. Soms zijn deze over het hoofd geziene bestanden goedaardig, zoals tussenliggende buildbestanden. Er is echter altijd het risico dat iemand per ongeluk gevoelige gegevens doorvoert. Iemand kan bijvoorbeeld een API-sleutel of persoonlijke configuratiegegevens doorvoeren die een kwaadwillende actor kan gebruiken. Een techniek om dit risico te voorkomen, is het bouwen en onderhouden van .gitignore bestanden. Deze bestanden instrueren clienthulpprogramma's, zoals het git opdrachtregelprogramma, om paden en patronen te negeren bij het verzamelen van bestanden voor een commit.

In het volgende voorbeeld ziet u enkele veelvoorkomende use cases voor het negeren van bestanden:

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

Uw opslagplaats kan meerdere .gitignore bestanden bevatten. Instellingen worden overgenomen van bovenliggende mappen, waarbij velden in nieuwe .gitignore-bestanden, die bestaande instellingen overschrijven, voorrang krijgen op bovenliggende instellingen voor hun mappen en submappen. Het is een aanzienlijke inspanning om het rootbestand .gitignore te onderhouden, hoewel het toevoegen van een .gitignore bestand in een projectmap handig kan zijn wanneer dat project specifieke vereisten heeft die gemakkelijker afzonderlijk van het bovenliggende project kunnen worden onderhouden, zoals bestanden die niet worden genegeerd.

Voor meer informatie over .gitignore, zie negeren van bestanden. Bekijk ook de verzameling starters-.gitignore bestanden die worden aangeboden voor verschillende platforms in de gitignore-opslagplaats.

Gevoelige gegevens uit een opslagplaats verwijderen

Hoewel .gitignore bestanden nuttig kunnen zijn bij het helpen voorkomen van het doorvoeren van gevoelige gegevens, zijn ze slechts een sterke suggestie. Ontwikkelaars kunnen nog steeds een .gitignore bestand omzeilen om bestanden toe te voegen als ze gemotiveerd genoeg zijn, en soms kunnen bestanden doorlopen omdat ze niet voldoen aan de .gitignore bestandsconfiguratie. Projectdeelnemers moeten altijd alert zijn op commits die gegevens bevatten die niet in de opslagplaats of de geschiedenis ervan moeten worden opgenomen.

Takbeschermingsregels

U kunt een vertakkingsbeveiligingsregel maken om bepaalde werkstromen voor een of meer vertakkingen af te dwingen. U kunt bijvoorbeeld een goedkeuringsbeoordeling vereisen of geslaagde statuscontroles voor alle pull requests die in de beschermde branch zijn samengevoegd.

U kunt de workflows gebruiken die de branch beveiligen om:

• Voer een build uit om te controleren of de codewijzigingen kunnen worden gebouwd;
• Voer een linter uit om te controleren op typfouten en naleving van de interne codeerconventies.
• Voer geautomatiseerde tests uit om te controleren op eventuele gedragswijzigingen van de code;
• Enzovoort.

Vereiste revisoren in pull-aanvragen

U kunt de beveiliging van de opslagplaats verbeteren door beoordelingen te vereisen voordat code wordt samengevoegd in belangrijke vertakkingen. Vereiste revisoren helpen bij het afdwingen van kwaliteit, beveiliging en verantwoordelijkheid.

Vereiste revisoren configureren:

1. Navigeer naar de opslagplaats op GitHub.
2. Klik onder de naam van de opslagplaats op Instellingen>vertakkingen.
3. Klik naast de vertakking die u wilt beveiligen op Regel toevoegen of een bestaande regel bewerken.
4. Selecteer Pull-aanvraagbeoordelingen vereisen voordat u samenvoegt.
5. Schakel desgewenst het volgende in:
   • Controle van code-eigenaren vereisen
   • Verouderde pull-aanvraaggoedkeuringen negeren wanneer nieuwe doorvoeringen worden gepusht
   • Goedkeuring vereisen van iemand anders dan de laatste pusher

Vereiste beoordelingen kunnen niet worden overgeslagen zonder beheerdersmachtigingen. Ze zorgen ervoor dat voorgestelde wijzigingen worden gecontroleerd door een andere inzender of aangewezen code-eigenaar voordat ze worden samengevoegd.

Zie Over beveiligde vertakkingen voor meer informatie.

Een CODEOWNERS-bestand toevoegen

Door een CODEOWNERS--bestand toe te voegen aan uw opslagplaats, kunt u afzonderlijke teamleden of hele teams toewijzen als code-eigenaren aan paden in uw opslagplaats. Deze code-eigenaren zijn vervolgens vereist voor beoordelingen van pull-aanvragen voor wijzigingen in bestanden in een pad waarvoor ze zijn geconfigureerd.

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

U kunt het bestand CODEOWNERS maken in de hoofdmap van de opslagplaats of in de map docs of .github.