Vanliga frågor och svar | Azure

Nej. Tillägget är inte tillgängligt för nedladdning och installation för Azure DevOps Server (tidigare Visual Studio Team Foundation Server).

Kanske. Det beror på typen av analysverktyg. Källkoden kan vara det enda som krävs, eller så kan kompileringsutdata krävas.

Till exempel analyserar CredScan filer i mappstrukturen för kodlagringsplatsen. På grund av den här analysen kan du köra bygguppgifterna CredScan och Publicera säkerhetsanalysloggar 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.

Ja. Du kan introducera en byggpaus när ett verktyg rapporterar ett problem eller problem i loggfilen. Lägg till bygguppgiften Efter analys och markera kryssrutan för alla verktyg som du vill bryta 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 endast fel eller både fel och varningar.

Vanligtvis är Azure DevOps-bygguppgifterna direkta omslutningar kring kommandoradsargumenten för säkerhetsverktygen. Du kan skicka som argument till en bygguppgift vad 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 för källkatalogen som tidigare angavs. 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 byggaktivitet ersätts den platsen med en sökväg till vår välkända plats för loggar på byggagenten
• Vissa andra kommandoradsargument ändras för vissa verktyg. Ett exempel är tillägg eller borttagning av alternativ som säkerställer att inget GUI startas.

Nej. Det går inte att köra säkra utvecklingsverktyg på flera lagringsplatser i en enda pipeline.

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 för byggagenten. Mer information om den här platsen finns i följande frågor.

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

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

I de flesta fall, ja.

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

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

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 samlingslistan för build-task. Annars har det ingen effekt att installera tillägget i Din Azure DevOps-organisation. Installationen ändrar inte några kontoinställningar, projektinställningar eller pipelines.

Nej. Om 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 din byggprocess.

Vanliga frågor och svar om uppgifter

Frågor som är specifika för att skapa uppgifter visas i det här avsnittet.

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

Så här utelämnar du 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."
    }
  ]
}

Så här utelämnar du alla hemligheter i en angiven fil eller utelämnar själva hemlighetsfilen

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

I följande exempel visas hur du utelämnar filen <InputPath> -\src\JS\lib\angular.js

Exempel på giltiga regler för undertryckning:

• <InputPath> -\src\JS\lib\angular.js – utelämnar filen i den angivna sökvägen
• \src\JS\lib\angular.js
• \JS\lib\angular.js
• \lib\angular.js
• angular.js – utelämnar 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"
    }
  ]
}

Följande resurser hjälper dig att på ett säkert sätt hantera hemligheter och komma åt känslig information inifrån dina program:

• Azure Key Vault
• Azure Active Directory (Azure AD)
• Azure AD hanterad tjänstidentitet (MSI)
• Hanterade identiteter för Azure-resurser
• Hanterade identiteter i Azure App Service och Azure Functions
• AppAuthentication-bibliotek

Mer information finns i blogginlägget Hantera hemligheter på ett säkert sätt i molnet.

Autentiseringsskannern 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ökare. Men du kan också implementera dina egna anpassade sökare.

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

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

• RuleId: Sökarens stabila ogenomskinliga ID:

  • En standardsökare för autentiseringsskanner tilldelas ett RuleId-värde som CSCAN0010, CSCAN0020 eller CSCAN0030. Den sista siffran är reserverad för potentiell sammanslagning eller uppdelning av sökgrupper via reguljära uttryck (regex).
  • RuleId-värdet för en anpassad sökare bör ha ett eget namnområde. Exempel är CSCAN-Namespace<> 0010, CSCAN-Namespace<> 0020 och CSCAN-Namespace<> 0030.
  • Ett fullständigt kvalificerat söknamn är kombinationen 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 har definierats returneras alla filer som matchar värdet ResourceMatchPattern .

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

• 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 allvarlighetsnivån har värdet 1.

  

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

Det fullständiga felmeddelandet:

"Fel: Projektet återställdes med Microsoft.NETCore.App version x.x.x, men med aktuella inställningar 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 kompilering eller publicering, men inte under återställningen."

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

Ett steg mellan huvudbygget och Roslyn Analyzeers-stegen kan ha försatt 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 utför en NuGet-återställning precis före steget Roslyn Analyzeers. Det här duplicerade steget kan försätta källträdet i ett byggbart tillstånd igen.

csc.exe kan inte skapa en analyzer-instans

Det fullständiga felmeddelandet:

"'csc.exe' avslutades med felkod 1 – En instans av analysatorn AAAA kan inte skapas från C:\BBBB.dll: Det gick inte att läsa in filen eller sammansättningen 'Microsoft.CodeAnalysis, Version=X.X.X.X, Culture=neutral, PublicKeyToken=31bf3856ad364e35' eller något av dess beroenden. Det går inte att hitta den angivna filen."

Se till att kompilatorn stöder Roslyn Analyzeers. Om du kör kommandot csc.exe /version bör du rapportera ett versionsvärde på 2.6 eller senare.

Ibland kan en .csproj-fil åsidosätta byggdatorns Visual Studio-installation genom att referera till ett paket från Microsoft.Net.Compilers. Om du inte tänker 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 felloggsökvägen, som anges i alternativet csc.exe /errorlog . Alternativet och sökvägen visas i loggen för Roslyn Analyzeers-bygguppgiften. De kan se ut ungefär som /errorlog:F:\ts-services-123_work\456\s\Some\Project\Code\Code.csproj.sarif

C#-kompilerarens version ä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. Kontrollera att du refererar till ett Microsoft.Net.Compilers NuGet-paket som är version 2.6 eller senare.

MSBuild- och VSBuild-loggar hittades inte

Roslyn Analyzeers-bygguppgiften måste fråga Azure DevOps om MSBuild-loggen från MSBuild-byggaktiviteten. Om analysaktiviteten körs omedelbart efter MSBuild-aktiviteten är loggen ännu inte tillgänglig. Placera andra aktiviteter mellan MSBuild-aktiviteten och Roslyn Analyzeers-aktiviteten. Exempel på andra uppgifter är BinSkim och Anti-Malware Scanner.

Nästa steg

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

• Onboarding: Se vår dokumentation om registrering

• Support: Email vårt team på Microsoft Security Code Analysis Support