Uwolnienie się od zakodowanych na stałe wartości: inteligentniejsze strategie dla nowoczesnego oprogramowania

Zakodowane na stałe wartości wyglądają jak skróty. Programista potrzebuje adresu URL bazy danych, wpisuje go bezpośrednio w ciągu połączenia i przechodzi dalej. Trzy miesiące później adres URL ulega zmianie, zmiana zostaje wprowadzona w jednym pliku, ale pominięta w czterech innych, a produkcja zostaje przerwana o 2 w nocy. Programista potrzebuje klucza API, wpisuje go do pliku źródłowego, zatwierdza zmiany i przesyła je do bazy. Sześć miesięcy później repozytorium zostaje sklonowane, klucz pojawia się w publicznym forku, a konto zostaje przejęte, zanim ktokolwiek to zauważy. To nie są przypadki skrajne. To standardowa ścieżka zakodowanych na stałe wartości w systemach oprogramowania: pozornie niegroźne skróty, które prowadzą do długów konserwacyjnych, incydentów bezpieczeństwa i niepowodzeń wdrożeń.

Rozwiązanie nie jest skomplikowane. Zmienne środowiskowe, pliki konfiguracyjne, wstrzykiwanie zależności i scentralizowane stałe to dobrze znane wzorce dostępne w każdym głównym języku programowania i frameworku. Wyzwaniem jest ich systematyczne stosowanie w istniejących bazach kodu, egzekwowanie ich w nowym kodzie i zbudowanie dyscypliny, aby wychwycić je, zanim trafią do produkcji. Poniżej omówiono każdą technikę niezbędną do tego celu, wraz z działającymi przykładami kodu dla języków Python, Java i JavaScript.

Czym jest wartość zakodowana na stałe?

Wartość zakodowana na stałe to stała dosłowna osadzona bezpośrednio w kodzie źródłowym, a nie dostarczana poprzez konfigurację, zmienne środowiskowe, bazę danych lub dane wejściowe środowiska wykonawczego. Jej cechą charakterystyczną jest brak pośredniości: jeśli zmiana wartości wymaga modyfikacji kodu źródłowego, ponownej kompilacji lub ponownego wdrożenia aplikacji, jest ona zakodowana na stałe.

Typowe przykłady:

• Ciąg połączenia z bazą danych wpisany bezpośrednio do klasy konfiguracji
• Klucz API lub token dostępu w pliku źródłowym
• Adres URL usługi wskazujący na określone środowisko
• Próg liczbowy (if (amount > 5000)) bez żadnego wyjaśnienia lub zewnętrznego źródła
• Ścieżka do pliku zakładająca określony układ serwera
• Ciąg roli użytkownika ("admin") rozproszone po kontrolach autoryzacji

Wartości zakodowane na stałe występują w każdym języku i każdej bazie kodu. Starsze aplikacje mainframe kodują nazwy zestawów danych, kody regionów i progi biznesowe specyficzne dla danego środowiska bezpośrednio w programach COBOL. Nowoczesne mikrousługi gromadzą zakodowane na stałe wartości limitów czasu, liczbę ponownych prób i adresy URL wykrywania usług w klasach aplikacji. Forma zmienia się wraz z językiem; problem jest ten sam.

Wartości zakodowane na stałe a stałe: jaka jest różnica?

Wartości zakodowane na stałe często mylone są ze stałymi, ale to rozróżnienie jest istotne. Stała reprezentuje stabilny, celowy fakt na poziomie domeny, który jest poprawny z definicji i raczej nie ulegnie zmianie: Math.PI, HTTP_STATUS_OK = 200, MAX_RETRY_ATTEMPTS = 3 (jeśli liczba trzy jest rzeczywiście poprawna w każdym kontekście). Stałe są odpowiednie w kodzie. Dodają przejrzystości, zapobiegają literówkom i jasno określają intencje.

Wartość zakodowana na stałe koduje założenie dotyczące kontekstu wdrożenia, infrastruktury lub reguł biznesowych, które prawdopodobnie będą się zmieniać. Adres URL produkcyjnej bazy danych, klucz API, regionalna stawka podatku, stan flagi funkcji: są to wartości zakodowane na stałe, maskujące się jako stałe. Test jest prosty: jeśli wartość musi być inna w innym środowisku, u innego klienta lub w innej wersji, nie jest to stała i nie powinna znajdować się w kodzie źródłowym.

Czym jest kodowanie miękkie?

Kodowanie miękkie to praktyka polegająca na tym, że wartości są konfigurowalne w czasie wykonywania, a nie stałe w momencie kompilacji. Wartość zakodowaną miękko można zmienić za pomocą pliku konfiguracyjnego, zmiennej środowiskowej, wpisu w bazie danych lub interfejsu administracyjnego, bez konieczności modyfikowania kodu źródłowego lub ponownego wdrażania aplikacji. Kodowanie miękkie to właściwe podejście w przypadku ustawień specyficznych dla danego środowiska, parametrów biznesowych, flag funkcji i wszelkich wartości, które mogą się różnić między środowiskiem programistycznym, testowym i produkcyjnym.

Różnica między kodowaniem twardym a kodowaniem miękkim polega na różnicy między systemem, który wymaga zmiany kodu i wdrożenia w celu aktualizacji stawki podatkowej, a systemem, który pozwala członkowi zespołu operacyjnego na jej aktualizację w pliku konfiguracyjnym i ponowne uruchomienie usługi. W dużej skali ta różnica oznacza tysiące godzin pracy inżynierów i znaczne ryzyko operacyjne.

Dlaczego kodowanie na sztywno jest złą praktyką

Niszczy utrzymywalność

Wartości zakodowane na stałe mnożą się. Adres URL usługi zakodowany na stałe w jednym pliku staje się zakodowany na stałe w pięciu plikach, gdy moduł jest kopiowany do nowej integracji. Magiczna liczba, która pojawia się w jednym obliczeniu, pojawia się w trzech, gdy ta sama logika jest replikowana w nieco innych kontekstach. Każda instancja to osobne zadanie konserwacyjne: znajdź ją, zaktualizuj, przetestuj aktualizację i miej nadzieję, że żadna instancja nie została pominięta.

Problem z utrzymywalnością to nie tylko kwestia wysiłku. To kwestia ryzyka. Wyszukiwanie i zamiana w bazie kodu w celu aktualizacji zakodowanej na stałe wartości to operacja refaktoryzacji, która ma wpływ na produkcję. Każda pominięta instancja to błąd. Każda nieprawidłowa zamiana to błąd. Jedynym sposobem na upewnienie się, że zmiana jest kompletna, jest zautomatyzowane testy, które zakończyłyby się niepowodzeniem, gdyby jakakolwiek instancja pozostała. Jednak właśnie zautomatyzowane testy utrudniają pisanie zakodowanych na stałe wartości.

Blokuje testowanie i CI/CD

Testy automatyczne muszą być uruchamiane w kontrolowanych środowiskach. Test, który łączy się z produkcyjną bazą danych, ponieważ ciąg połączenia jest zakodowany na stałe, nie jest testem; jest to operacja produkcyjna, która jest uruchamiana podczas kompilacji. Potok CI, który ulega awarii z powodu braku dostępu do zakodowanego na stałe adresu URL usługi z serwera kompilacji, nie jest problemem infrastruktury testowej; jest to problem zakodowania na stałe.

Zmienne środowiskowe i wstrzykiwanie konfiguracji sprawiają, że ten sam zestaw testów można uruchomić w lokalnych środowiskach programistycznych, CI, przejściowych i produkcyjnych z różnymi usługami wsparcia. Bez nich testy stają się specyficzne dla danego środowiska, niestabilne i ostatecznie porzucane.

Tworzy poważne luki w zabezpieczeniach

Zakodowane na stałe dane uwierzytelniające to jedna z najczęstszych i najczęściej wykorzystywanych kategorii luk w zabezpieczeniach oprogramowania. Zakodowany na stałe klucz API, hasło do bazy danych lub token dostępu, który został zatwierdzony w systemie kontroli wersji, pozostaje w historii repozytorium nawet po usunięciu z bieżącej gałęzi. Automatyczne skanery stale przeszukują publiczne repozytoria w poszukiwaniu tych wzorców. Klucz znaleziony w zatwierdzeniu sprzed osiemnastu miesięcy jest nadal ważny, jeśli nigdy nie został poddany rotacji.

OWASP jednoznacznie identyfikuje hasła zakodowane na stałe jako krytyczną lukę bezpieczeństwa (CWE-259, CWE-798). Wytyczne NIST wymagają, aby dane uwierzytelniające nigdy nie były przechowywane w kodzie źródłowym. Mimo to, wycieki danych uwierzytelniających poprzez wartości zakodowane na stałe pozostają jedną z najczęstszych przyczyn incydentów bezpieczeństwa w chmurze.

Ryzyko wykracza poza dane uwierzytelniające. Zakodowane na stałe wewnętrzne adresy URL usług ujawniają topologię infrastruktury. Zakodowane na stałe ciągi znaków ról użytkownika ujawniają logikę autoryzacji. Zakodowane na stałe progi walidacji można ominąć, gdy atakujący zna ich dokładne wartości. Żadne z nich nie jest od razu oczywiste jako zagrożenie bezpieczeństwa, dlatego kumulują się bez podjęcia odpowiednich działań.

Zakodowane na stałe dane uwierzytelniające i klucze API: kategoria najwyższego ryzyka

Zakodowane na stałe sekrety zasługują na osobne traktowanie, ponieważ konsekwencje ich błędnego odczytania różnią się zasadniczo od innych problemów z kodowaniem na stałe. Zakodowana na stałe wartość limitu czasu powoduje błąd. Zakodowany na stałe klucz API powoduje naruszenie bezpieczeństwa.

Jak wyglądają zakodowane na stałe dane uwierzytelniające

pyton

# Python -- hardcoded database credentials (never do this)
connection = psycopg2.connect(
    host="prod-db.internal.example.com",
    database="accounts",
    user="app_service",
    password="s3cr3tP@ssword!"   # hardcoded secret in source code
)

# Python -- correct approach: load from environment
import os
connection = psycopg2.connect(
    host=os.environ["DB_HOST"],
    database=os.environ["DB_NAME"],
    user=os.environ["DB_USER"],
    password=os.environ["DB_PASSWORD"]
)

Jawa

// Java -- hardcoded API key (never do this)
private static final String API_KEY = "sk-prod-a1b2c3d4e5f6g7h8i9j0";

// Java -- correct approach: load from environment
private static final String API_KEY = System.getenv("OPENAI_API_KEY");

Jak naprawić zakodowane na stałe dane uwierzytelniające

Zmienne środowiskowe to standardowe rozwiązanie w zakresie obsługi sekretów w aplikacjach wdrożonych. Sekret jest ustawiany w środowisku wdrożeniowym (serwerze, kontenerze, sekretie Kubernetes lub menedżerze sekretów w chmurze) i dostępny w czasie wykonywania. Kod źródłowy nie zawiera wartości sekretu, a jedynie nazwę klucza użytą do jego pobrania.

Usługi zarządzania sekretami , takie jak AWS Secrets Manager, HashiCorp Vault, Azure Key Vault i Google Secret Manager, to podejście klasy produkcyjnej do rotacji, audytu i dystrybucji sekretów w ramach usług. Aplikacja pobiera sekret podczas uruchamiania (lub na żądanie) z repozytorium, a nie ze zmiennej środowiskowej, zapewniając rotację bez ponownego wdrażania i pełny dziennik audytu każdego dostępu.

.env pliki (korzystając z bibliotek takich jak python-dotenv or dotenv w Node.js) nadają się do lokalnego rozwoju. Zapewniają ten sam interfejs co zmienne środowiskowe, ale ładują się z pliku lokalnego. Kluczowa zasada: .env pliki muszą być w .gitignore i nigdy nie wolno do tego dopuścić.

Wykrywanie już popełnionych sekretów: jeśli sekret został zakodowany na stałe i zatwierdzony, należy go uznać za naruszony i natychmiast poddać rotacji. Usunięcie wartości z bieżącej gałęzi nie powoduje usunięcia jej z historii git. Narzędzia takie jak git-filter-branch lub BFG Repo Cleaner może wyczyścić historię, ale najbezpieczniejszym założeniem po zatwierdzeniu jest to, że sekret został ujawniony.

Jak zapobiegać zakodowanym na stałe kluczom API

W przypadku kluczy API stron trzecich alternatywy dla kodowania na stałe zależą od kontekstu:

• Aplikacje po stronie serwera:zmienne środowiskowe lub usługi zarządzania tajnymi danymi
• Potoki CI / CD: zmienne sekretów potoku (sekrety GitHub Actions, zmienne GitLab CI)
• Aplikacje mobilne:Klucze API nigdy nie powinny znajdować się w kodzie po stronie klienta; należy używać serwera proxy zaplecza, który wywołuje API z kluczem przechowywanym po stronie serwera
• Agenci AI i integracje LLM:ładuj klucze API ze środowiska podczas inicjalizacji agenta, nigdy nie przekazuj ich jako zakodowanych na stałe ciągów w monitach lub wywołaniach funkcji

Bezpieczne kodowanie RPG na platformie IBM i opiera się na tej samej zasadzie: zewnętrzne obszary danych, kolejki danych i wartości systemowe powinny zawierać parametry połączenia specyficzne dla danego środowiska, zamiast kodować je w kodzie źródłowym programu.

Jak zapobiegać zakodowanym wartościom: kompletne wzorce z kodem

Zmienne środowiskowe

Zmienne środowiskowe to najbardziej uniwersalne rozwiązanie. Obsługuje je każdy główny system operacyjny, platforma chmurowa, system konteneryzacji i framework wdrożeniowy.

pyton

# Python: load all configuration from environment
import os
from dotenv import load_dotenv

load_dotenv()  # loads .env file in development; ignored in production

DATABASE_URL = os.environ["DATABASE_URL"]
API_BASE_URL = os.environ.get("API_BASE_URL", "https://api.example.com")
MAX_RETRIES  = int(os.environ.get("MAX_RETRIES", "3"))
DEBUG_MODE   = os.environ.get("DEBUG", "false").lower() == "true"

javascript

// Node.js: access environment variables
require('dotenv').config();  // load .env in development

const config = {
  dbUrl:      process.env.DATABASE_URL,
  apiKey:     process.env.API_KEY,
  port:       parseInt(process.env.PORT, 10) || 3000,
  debug:      process.env.NODE_ENV !== 'production',
};

Jawa

// Java: environment variables via System.getenv()
public class AppConfig {
    public static final String DB_URL  = System.getenv("DATABASE_URL");
    public static final String API_KEY = System.getenv("THIRD_PARTY_API_KEY");
    public static final int    TIMEOUT = Integer.parseInt(
        Optional.ofNullable(System.getenv("REQUEST_TIMEOUT_MS")).orElse("5000")
    );
}

Pliki konfiguracyjne

Pliki konfiguracyjne eksternalizują wartości specyficzne dla środowiska, ale nie będące tajnymi, takie jak nazwy usług, flagi funkcji, rozmiary stronicowania i wartości TTL pamięci podręcznej.

jamla

# config/production.yaml
database:
  host: prod-db.internal
  port: 5432
  pool_size: 20

api:
  base_url: https://api.partner.com/v2
  timeout_ms: 3000
  max_retries: 3

features:
  new_checkout: true
  beta_dashboard: false

pyton

# Load at startup; never hardcode the values it contains
import yaml

with open(f"config/{os.environ['APP_ENV']}.yaml") as f:
    config = yaml.safe_load(f)

timeout = config["api"]["timeout_ms"]

Wstrzykiwanie zależności

Wstrzykiwanie zależności polega na przekazywaniu skonfigurowanych wartości do komponentów zamiast zmuszania ich do tworzenia lub pobierania własnej konfiguracji. Dzięki temu komponenty można testować w izolacji i konfigurować w obrębie danego środowiska.

Jawa

// Spring Boot: inject configuration via @Value
@Service
public class PaymentService {
    @Value("${payment.api.url}")
    private String apiUrl;

    @Value("${payment.api.timeout-ms}")
    private int timeoutMs;

    // No hardcoded URL or timeout anywhere in this class
    public PaymentResult process(Payment payment) {
        // uses apiUrl and timeoutMs injected from application.properties
    }
}

pyton

# Python: simple constructor injection
class EmailService:
    def __init__(self, smtp_host: str, smtp_port: int, api_key: str):
        self.smtp_host = smtp_host
        self.smtp_port = smtp_port
        self.api_key   = api_key

# Wire at application startup, reading from environment
email_service = EmailService(
    smtp_host=os.environ["SMTP_HOST"],
    smtp_port=int(os.environ["SMTP_PORT"]),
    api_key=os.environ["EMAIL_API_KEY"],
)

Centralizowane stałe i wyliczenia

Wartości, które są rzeczywiście ustalone na stałe, takie jak kody stanu HTTP, stany specyficzne dla domeny, identyfikatory protokołów, powinny znajdować się w pojedynczym, nazwanym module stałych, a nie być rozproszone jako literały ciągów.

pyton

# Python: centralised constants
from enum import Enum

class OrderStatus(Enum):
    PENDING   = "pending"
    CONFIRMED = "confirmed"
    SHIPPED   = "shipped"
    DELIVERED = "delivered"
    CANCELLED = "cancelled"

# Usage: no magic strings scattered across modules
if order.status == OrderStatus.CONFIRMED:
    notify_warehouse(order)

Jawa

// Java: enum with business meaning
public enum UserRole {
    ADMIN("admin"),
    EDITOR("editor"),
    VIEWER("viewer");

    private final String value;
    UserRole(String value) { this.value = value; }
    public String getValue() { return value; }
}

// Replaces scattered "admin", "editor", "viewer" strings
if (user.getRole() == UserRole.ADMIN) {
    grantFullAccess(user);
}

Kodowanie na stałe w określonych językach

Czym jest hardcoding w Pythonie?

W Pythonie kodowanie na sztywno najczęściej pojawia się jako literały ciągów znaków dla adresów URL i danych uwierzytelniających, stałe numeryczne w logice biznesowej oraz ścieżki do plików zakładające określoną strukturę katalogów. os.environ oraz python-dotenv są standardowymi mechanizmami konfiguracji opartej na środowisku. configparser moduł obsługuje pliki konfiguracyjne w formacie INI. pydantic-settings zapewnia konfigurację sprawdzoną pod kątem typu na podstawie zmiennych środowiskowych z wartościami domyślnymi, co jest zalecanym podejściem w przypadku produkcyjnych usług Python.

Wykrywanie zakodowanych na stałe wartości w Pythonie: narzędzia do analizy statycznej, w tym Bandit (do zakodowania na stałe wartości związanych z bezpieczeństwem, takich jak hasła i klucze), Pylint i Semgrep, potrafią automatycznie identyfikować zakodowane na stałe dane uwierzytelniające i liczby magiczne.

Czym jest hardcoding w Javie?

W Javie wartości zakodowane na stałe często pojawiają się jako private static final String pola, @Value Adnotacje z domyślnymi wartościami wbudowanymi, które powinny być eksternalizowane, oraz literały w logice biznesowej. Spring Boot application.properties oraz application.yml Pliki są standardowym mechanizmem eksternalizacji. @ConfigurationProperties-klasy adnotowane zapewniają bezpieczne pod względem typu, sprawdzone obiekty konfiguracji z plików YAML lub właściwości.

Wykrywanie wartości zakodowanych na stałe w Javie: SpotBugs z wtyczką Find Security Bugs wykrywa zakodowane na stałe dane uwierzytelniające. SonarQube sygnalizuje magiczne liczby, zakodowane na stałe adresy URL i zakodowane na stałe hasła. SMART TS XLAnaliza przedsiębiorstwa obejmuje bazy kodu Java, COBOL i inne starsze języki.

Kodowanie na stałe w kodzie starszym i mainframe’owym

Programy w językach COBOL, RPG i PL/I na komputerach mainframe IBM i systemach klasy średniej mają specyficzne wzorce kodowania na sztywno: nazwy zbiorów danych osadzone w instrukcjach DD, identyfikatory środowisk w logice programu oraz progi biznesowe kompilowane bezpośrednio w programach. Eksternalizacja tych wartości wymaga narzędzi obsługujących komputery mainframe: parametrów systemowych (SYSPARM), zewnętrznych obszarów danych, tabel konfiguracyjnych w DB2 oraz sparametryzowanego języka JCL. Do wykrywania tych wzorców na dużą skalę niezbędne są narzędzia do analizy statycznej obsługujące języki mainframe.

Refaktoryzacja w świecie rzeczywistym: od zakodowanego na stałe do konfigurowalnego

Trójfazowe podejście do refaktoryzacji

Faza 1: Odkrywanie. Przeprowadź analizę statyczną całej bazy kodu, aby utworzyć inwentaryzację zakodowanych na stałe wartości, pogrupowanych według typu (dane uwierzytelniające, adresy URL, logika biznesowa, liczby magiczne) i poziomu ryzyka. Nadaj priorytet danym uwierzytelniającym i wartościom specyficznym dla produkcji.

Faza 2: Eksternalizacja według kategorii. Zacznij od poświadczeń (największe ryzyko): przenieś wszystkie sekrety do zmiennych środowiskowych lub menedżera sekretów. Następnie zajmij się adresami URL i nazwami usług specyficznymi dla danego środowiska. Następnie zajmij się progami logiki biznesowej. Na koniec zajmij się liczbami magicznymi, zastępując je nazwanymi stałymi lub wartościami konfiguracyjnymi.

Faza 3: Egzekwowanie. Dodaj statyczne kontrole analizy do potoku CI, które nie powiodą się w przypadku nowych, zakodowanych na stałe danych uwierzytelniających. Dodaj reguły lintingu, które sygnalizują „magiczne” liczby. Dodaj elementy listy kontrolnej przeglądu kodu. Celem jest utrudnienie dodawania zakodowanej na stałe wartości niż użycie prawidłowego wzorca.

Identyfikacja wartości zakodowanych na stałe w starszych projektach

W starszych projektach, w których na przestrzeni lat kumulowały się zakodowane wartości:

• Zastosowanie grep lub przeszukaj repozytorium pod kątem typowych wzorców: ciągów połączeń, password, apikey, wzorce adresów IP i znane nazwy usług
• Uruchom narzędzia do analizy statycznej (Bandit, SonarQube, Semgrep, SMART TS XL) aby uzyskać kompletny spis bez konieczności ręcznego przeglądania poszczególnych plików
• Sprawdź historię git pod kątem sekretów, które zostały wcześniej zatwierdzone i usunięte. Nadal są dostępne w historii repozytorium
• Szukaj wartości, które pojawiają się identycznie w wielu plikach – są to kandydaci do centralizacji

Zapobieganie wprowadzaniu wartości zakodowanych na stałe

• Haki pre-commitowe: uruchom skanowanie poświadczeń (np. detect-secrets, git-secrets, truffleHog) przy każdym zatwierdzeniu przed dotarciem do repozytorium
• Bramy rurociągów CI: kompilacje zakończone niepowodzeniem, które zawierają nowo wprowadzone wyniki analizy statycznej dla poświadczeń lub magicznych liczb
• Listy kontrolne przeglądu kodu: jawne elementy do eksternalizacji konfiguracji w procesie przeglądu zespołu
• Wdrażanie programistów:ustaw poprawne wzorce jako domyślne, dostarcz szablon projektu, który już używa zmiennych środowiskowych i .env.example filet

W jaki sposób SMART TS XL Eliminuje zakodowane na stałe wartości na dużą skalę

Ręczne wyszukiwanie i polecenie grep wystarczą do znalezienia oczywistych przypadków w małych bazach kodu. W systemach korporacyjnych obejmujących miliony wierszy kodu w językach COBOL, Java, Python, .NET, RPG i SQL, kompleksowe wykrywanie wartości zakodowanych na stałe wymaga zautomatyzowanej analizy strukturalnej. SMART TS XL wykonuje analizę statyczną we wszystkich tych językach jednocześnie, tworząc ujednolicony model odniesień krzyżowych, który identyfikuje:

• Wartości ciągu literalnego w parametrach połączenia i wywołaniach uwierzytelniania, oznaczone jako potencjalne ujawnienie danych uwierzytelniających
• Magiczne liczby w logice biznesowej porównywane z konfigurowalną linią bazową, identyfikujące wartości, które są niespójne w różnych modułach lub pojawiają się z różnymi wartościami w różnych miejscach
• Duplikujące się wartości literałowe, które pojawiają się w wielu plikach, ale służą temu samemu logicznemu celowi, wskazując na możliwości centralizacji
• Wartości w programach COBOL kodujące identyfikatory specyficzne dla środowiska, zwykle zarządzane za pomocą parametrów JCL
• Ścieżki przepływu danych od wartości zakodowanych na stałe przez system, pokazujące, które operacje w dół rzeki od nich zależą przed podjęciem decyzji o refaktoryzacji

Funkcja statycznej analizy kodu zapewnia inwentaryzację. Funkcja analizy wpływu pokazuje, na co wpłynie zastąpienie zakodowanej na stałe wartości. Funkcja modernizacji starszych wersji rozszerza tę funkcjonalność na scenariusze międzyjęzykowe i międzyplatformowe, w których ta sama wartość logiczna jest zakodowana na stałe niezależnie w programie mainframe i w usłudze Java, co wymaga skoordynowanych działań naprawczych zamiast pojedynczych poprawek.

W szczególności dla zespołów zarządzających długiem zabezpieczonym, SMART TS XLWykrywanie zakodowanych na stałe danych uwierzytelniających jest zintegrowane z procesami CI/CD jako bramka kompilacji: nowe zatwierdzenia wprowadzające zakodowane na stałe dane uwierzytelniające automatycznie powodują niepowodzenie kompilacji, zanim kod dotrze do repozytorium, w którym mógłby zostać ujawniony.

Hardcoding to problem dyscypliny, a nie wiedzy

Większość programistów, którzy zapisują wartości na sztywno, wie, że nie powinni tego robić. Wiedza o istnieniu zmiennych środowiskowych, o tym, że pliki konfiguracyjne to właściwe podejście i że dane uwierzytelniające nigdy nie powinny znajdować się w kodzie źródłowym, jest powszechnie dostępna i powszechnie rozumiana. Problemem nie jest wiedza: problemem jest dyscyplina pod presją.

Terminy dostaw sprawiają, że konfiguracja zmiennych środowiskowych wydaje się zbędna. W przypadku starszych baz kodu, eksternalizacja wydaje się bardziej ryzykowna niż pozostawienie wartości bez zmian. Duże zespoły z niespójnym procesem wdrażania ułatwiają nowym programistom kopiowanie istniejących wzorców, które okazują się błędne. Dlatego zajęcie się kwestią hardcodingu w skali organizacji wymaga czegoś więcej niż tylko dokumentacji: wymaga automatycznego egzekwowania, które sprawia, że ​​błędny wzorzec jest trudniejszy do wdrożenia niż poprawny.

Haki pre-commit, które odrzucają zatwierdzenia zawierające sekrety, potoki CI, które nie działają po wprowadzeniu nowych magicznych liczb, listy kontrolne przeglądu kodu, które wyraźnie pytają o eksternalizację konfiguracji, oraz narzędzia do analizy statycznej, które ujawniają pełny zakres istniejących, zakodowanych na stałe wartości w bazie kodu: to mechanizmy, które niwelują lukę między znajomością właściwego podejścia a jego konsekwentnym stosowaniem. Przykłady kodu i wzorce w tym artykule stanowią techniczne podstawy. Mechanizmy egzekwowania są tym, co sprawia, że ​​są one skuteczne.