Vanliga frågor och svar | Azure

Anteckning

Från och med den 1 mars 2022 kommer msca-tillägget (Microsoft Security Code Analysis) att dras tillbaka. Befintliga MSCA-kunder behåller sin åtkomst till MSCA till och med 1 mars 2022. Se OWASP Source Code Analysis Tools för alternativa alternativ i Azure DevOps. Kunder som planerar att migrera till GitHub kan läsa mer i GitHub Advanced Security.

Har du några frågor? Mer information finns i följande vanliga frågor och svar.

Allmänna vanliga frågor och svar

Kan jag installera tillägget på min Visual Studio Team Foundation Server-instans i stället för på en Azure DevOps-instans?

Nej. Tillägget är inte tillgängligt för nedladdning och installation för Visual Studio Team Foundation Server.

Måste jag köra Microsoft Security Code Analysis med mitt bygge?

Kanske. Det beror på typen av analysverktyg. Källkoden kan vara det enda som krävs, eller så kan du behöva skapa utdata.

Till exempel analyserar Credential Scanner (CredScan) filer i mappstrukturen för koddatabasen. På grund av den här analysen kan du köra build-uppgifterna CredScan och Publish Security Analysis Logs i en fristående version för att få resultat.

För andra verktyg som BinSkim som analyserar artefakter efter bygget krävs bygget först.

Kan jag bryta mitt bygge när resultat hittas?

Ja. Du kan introducera en byggbrytning när ett verktyg rapporterar ett problem i loggfilen. Lägg bara till uppgiften Post-Analysis build (Efteranalys) och markera kryssrutan för alla verktyg som du vill dela upp bygget för.

I användargränssnittet för uppgiften Efter analys kan du välja att bryta bygget när ett verktyg rapporterar antingen fel eller både fel och varningar.

Hur skiljer sig kommandoradsargumenten i Azure DevOps från de argumenten i de fristående skrivbordsverktygen?

I de flesta fall är Bygguppgifter för Azure DevOps direkta omslutningar runt kommandoradsargumenten för säkerhetsverktygen. Du kan skicka som argument till en bygguppgift allt du normalt skickar till ett kommandoradsverktyg.

Märkbara skillnader:

  • Verktyg körs från källmappen för agenten $(Build.SourcesDirectory) eller från %BUILD_SOURCESDIRECTORY%. Ett exempel är C:\agent _ work\1\s.
  • Sökvägarna i argumenten kan vara relativa till roten i källkatalogen som tidigare listats. Sökvägar kan också vara absoluta. Du får absoluta sökvägar antingen med hjälp av Azure DevOps Build Variables eller genom att köra en lokal agent med kända distributionsplatser för lokala resurser.
  • Verktygen tillhandahåller automatiskt en sökväg eller mapp för utdatafilen. Om du anger en utdataplats för en bygguppgift ersätts den platsen med en sökväg till vår välkända plats för loggar på byggaragenten
  • Vissa ytterligare kommandoradsargument har ändrats för vissa verktyg. Ett exempel är tillägg eller borttagning av alternativ som säkerställer att inget grafiskt användargränssnitt startas.

Kan jag köra en bygguppgift som Skanner för autentiseringsuppgifter på flera lagringsplatsen i en Azure DevOps-version?

Nej. Det finns inte stöd för att köra säkra utvecklingsverktyg på flera lagringsplatsen i en enda pipeline.

Den utdatafil som jag angav skapas inte, eller så kan jag inte hitta den utdatafil som jag har angett

Bygguppgifterna filtrerar vissa användarindata. För den här frågan uppdaterar de platsen för den genererade utdatafilen så att den blir en gemensam plats på byggagenten. Mer information om den här platsen finns i följande frågor.

Var genereras utdatafilerna från verktygen som sparats?

Bygguppgifterna lägger automatiskt till utdatasökvägar till den här välkända platsen på byggagen: $(Agent.BuildDirectory) _ sdt\logs. Eftersom vi standardiserar på den här platsen har alla team som producerar eller använder kodanalysloggar åtkomst till utdata.

Kan jag köa en version för att köra dessa uppgifter på en värdad bygga agent?

Ja. Alla uppgifter och verktyg i tillägget kan köras på en värdindelad byggagen.

Anteckning

Build-uppgiften Anti-Malware Scanner kräver en byggagen med Windows Defender aktiverat. Värdindelade Visual Studio 2017 och senare tillhandahåller en sådan agent. Build-uppgiften körs inte på den värd Visual Studio 2015-agenten.

Signaturer kan inte uppdateras på dessa agenter, men signaturer bör alltid vara mindre än tre timmar gamla.

Kan jag köra dessa bygguppgifter som en del av en lanseringspipeline i stället för en bygg-pipeline?

I de flesta fall ja.

Azure DevOps stöder dock inte körning av uppgifter i lanseringspipelines när dessa uppgifter publicerar artefakter. Den här bristen på stöd förhindrar att uppgiften Publicera säkerhetsanalysloggar körs i en lanseringspipeline. Uppgiften misslyckas i stället med ett beskrivande felmeddelande.

Varifrån laddar bygguppgifterna ned verktygen?

Bygguppgifter kan ladda ned verktygens NuGet-paket från Azure DevOps Package Management-flödet. Build-uppgifter kan också använda Node Package Manager, som måste förinstalleras på build-agenten. Ett exempel på en sådan installation är kommandot npm install tslint.

Vilken effekt har installationen av tillägget på Azure DevOps-organisationen?

När de installeras blir de säkerhetsbygguppgifter som tillhandahålls av tillägget tillgängliga för alla användare i din organisation. När du skapar eller redigerar en Azure-pipeline är dessa uppgifter tillgängliga från listan med bygguppgifter. I annat fall har installationen av tillägget i Din Azure DevOps-organisation ingen effekt. Installationen ändrar inte några kontoinställningar, projektinställningar eller pipelines.

Ändrar installationen av tillägget mina befintliga Azure Pipelines?

Nej. När du installerar tillägget blir säkerhetsbygguppgifterna tillgängliga för tillägg till dina pipelines. Du måste fortfarande lägga till eller uppdatera byggdefinitioner så att verktygen kan fungera med byggprocessen.

Uppgiftsspecifika vanliga frågor och svar

Frågor som är specifika för bygguppgifter visas i det här avsnittet.

Skanner för autentiseringsuppgifter

Vad är vanliga undertryckningsscenarier och exempel?

Här är information om två av de vanligaste undertryckningsscenarierna.

Ignorera alla förekomster av en viss hemlighet inom den angivna sökvägen

Hash-nyckeln för hemligheten från CredScan-utdatafilen krävs enligt följande exempel.

{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "hash": "CLgYxl2FcQE8XZgha9/UbKLTkJkUh3Vakkxh2CAdhtY=",
        "_justification": "Secret used by MSDN sample, it is fake."
    }
  ]
}

Varning

Hash-nyckeln genereras av en del av det matchande värdet eller filinnehållet. Alla källkodsrevisioner kan ändra hash-nyckeln och inaktivera undertryckningsregeln.

Ignorera alla hemligheter i en angiven fil eller förhindra själva hemlighetsfilen

Filuttrycket kan vara ett filnamn. Det kan också vara basename-delen av en fullständig filsökväg eller ett filnamn. Jokertecken stöds inte.

I följande exempel visas hur du ignorerar <InputPath>\src\JS\lib\angular.js

Exempel på giltiga undertryckningsregler:

  • <InputPath>\src\JS\lib\angular.js – undertrycker filen på den angivna sökvägen
  • \src\JS\lib\angular.js
  • \JS\lib\angular.js
  • \lib\angular.js
  • angular.js – undertrycker alla filer med samma namn
{
    "tool": "Credential Scanner",
    "suppressions": [
    {
        "file": "\\files\\AdditonalSearcher.xml", 
        "_justification": "Additional CredScan searcher specific to my team"
    },
    {
        "file": "\\files\\unittest.pfx", 
        "_justification": "Legitimate UT certificate file with private key"
    }
  ]
}

Varning

Alla framtida hemligheter som läggs till i filen ignoreras också automatiskt.

Vilka är rekommenderade riktlinjer för att hantera hemligheter?

Följande resurser hjälper dig att på ett säkert sätt hantera hemligheter och få åtkomst till känslig information från dina program:

Mer information finns i blogginlägget Managing Secrets Securely in the Cloud.

Kan jag skriva egna anpassade sökverktyg?

Skannern för autentiseringsuppgifter förlitar sig på en uppsättning innehållssökare som ofta definieras i buildsearchers.xml filen. Filen innehåller en matris med XML-serialiserade objekt som representerar ett ContentSearcher-objekt. Programmet distribueras med en uppsättning vältestade sökere. Men du kan även implementera egna anpassade sökverktyg.

En innehållssökare definieras på följande sätt:

  • Namn: Det beskrivande söknamnet som ska användas i utdatafilerna för skannern för autentiseringsuppgifter. Vi rekommenderar att du använder namngivningskonventionen för kamelfall för söknamn.

  • RuleId: Det stabila täckande ID:t för sökaren:

    • En standardsökare för skanner för autentiseringsuppgifter tilldelas ett RuleId-värde som CSCAN0010, CSCAN0020 eller CSCAN0030. Den sista siffran är reserverad för potentiellt sammanslagning eller delning av sökgrupper via reguljära uttryck (regex).
    • RuleId-värdet för en anpassad sökare ska ha ett eget namnområde. Exempel är CSCAN- <Namespace> 0010, CSCAN- <Namespace> 0020 och CSCAN- <Namespace> 0030.
    • Ett fullständigt kvalificerat söknamn är en kombination av ett RuleId-värde och ett söknamn. Exempel är CSCAN0010. KeyStoreFiles och CSCAN0020. Base64EncodedCertificate.
  • ResourceMatchPattern: Regex av filnamnstillägg för att kontrollera mot sökaren.

  • ContentSearchPatterns: En matris med strängar som innehåller regex-instruktioner som ska matchas. Om inga sökmönster definieras returneras alla filer som matchar ResourceMatchPattern-värdet.

  • ContentSearchFilters: En matris med strängar som innehåller regex-instruktioner för att filtrera sökspecifika falska positiva resultat.

  • MatchDetails: Ett beskrivande meddelande, åtgärdsinstruktioner eller båda som ska läggas till för varje matchning av sökaren.

  • Rekommendation: Innehållet i förslagsfältet för en matchning med hjälp av PREfast-rapportformatet.

  • Allvarlighetsgrad: Ett heltal som återspeglar allvarlighetsgraden för ett problem. Den högsta allvarlighetsgraden har värdet 1.

    XML som visar konfiguration av skanner för autentiseringsuppgifter

Roslyn-analysverktyg

Vad är vanliga fel när du använder uppgiften Roslyn Analyzers?

Projektet återställdes med fel version Microsoft.NETCore.App versionen

Det fullständiga felmeddelandet:

"Fel: Projektet återställdes med hjälp Microsoft.NETCore.App x.x.x, men med de aktuella inställningarna skulle version y.y.y användas i stället. Lös problemet genom att kontrollera att samma inställningar används för återställning och för efterföljande åtgärder som att skapa eller publicera. Det här problemet kan vanligtvis inträffa om egenskapen RuntimeIdentifier anges under kom build eller publish men inte under återställningen."

Eftersom Roslyn Analyzers-uppgifter körs som en del av kompileringen måste källträdet på byggdatorn vara i ett byggbart tillstånd.

Ett steg mellan din huvudbygge och Roslyn Analyzers-stegen kan ha fört källträdet i ett tillstånd som förhindrar skapande. Det här extra steget är förmodligen dotnet.exe publicera. Prova att duplicera steget som gör en NuGet-återställning precis före Roslyn Analyzers-steget. Det här duplicerade steget kan föra tillbaka källträdet i ett byggbart tillstånd.

csc.exe kan inte skapa en analysinstans

Det fullständiga felmeddelandet:

"'csc.exe' exited with error code 1 -- An instance of analyzer AAAA cannot be created from C: \ BBBB.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Systemet kan inte hitta den angivna filen."

Se till att kompilatorn stöder Roslyn Analyzers. Om du kör kommandotcsc.exe /version rapportera versionsvärdet 2.6 eller senare.

Ibland kan en .csproj-fil åsidosätta byggdatorns Visual Studio genom att referera till ett paket från Microsoft.Net.Compilers. Om du inte planerar att använda en specifik version av kompilatorn tar du bort referenser till Microsoft.Net.Compilers. Annars kontrollerar du att versionen av det refererade paketet också är 2.6 eller senare.

Försök att hämta sökvägen till felloggen, som anges i csc.exe /errorlog. Alternativet och sökvägen visas i loggen för roslyn analyzers-build-uppgiften. De kan se ut ungefär så här: /errorlog:F:\ts-services-123 _ work\456\s\Some\Project\Code\Code.csproj.sa smtp

C#-kompileringsversionen är inte tillräckligt ny

Om du vill hämta de senaste versionerna av C#-kompilatorn går du till Microsoft.Net.Compilers. Hämta den installerade versionen genom att köracsc.exe /version i en kommandotolk. Se till att du refererar till ett Microsoft.Net.Compilers NuGet-paket som är version 2.6 eller senare.

MSBuild- och VSBuild-loggar hittades inte

Roslyn Analyzers-build-uppgiften måste fråga Azure DevOps efter MSBuild-loggen från MSBuild-build-uppgiften. Om analysuppgiften körs omedelbart efter MSBuild-uppgiften är loggen ännu inte tillgänglig. Placera andra uppgifter mellan MSBuild-uppgiften och Roslyn Analyzers-uppgiften. Exempel på andra uppgifter är BinSkim och Skanner mot skadlig kod.

Nästa steg

Om du behöver ytterligare hjälp är Microsoft Security Code Analysis Support tillgängligt måndag till fredag från 9:00 till 17:00 Pacific, normaltid.